Add vcore_entry to vcpd (XCC) (2/2)
authorKevin Klues <klueska@cs.berkeley.edu>
Sat, 18 Jul 2015 17:01:26 +0000 (10:01 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Wed, 22 Jul 2015 19:17:58 +0000 (15:17 -0400)
commit80d402028aacc1866d60c013b0038fcb933c5a3b
treee23dc02be046cfe55ec52b5e1da9fec9a205a1dc
parentcffb4c2453aad856546f5d52e12f3006c6b32f01
Add vcore_entry to vcpd (XCC) (2/2)

In this commit we finalize the migration of vcore_entry into the vcpd.
As part of this, a significant amount of cleanup has been done.  In
addition to removing all system dependent startup code from glibc, we
also now only initialize __vcore_id, __vcore_context, and only call
__ctype_init() once when a vcore's TLS is first allocated.

Currently, the vcore entry point is set to point to a static function
called __kernel_vcore_entry, whose sole job is to grab the vcore_id of
the vcore passed in by the kernel, and set up the vcore's TLS by
extracting it from the vcpd for that vcore.  It then calls the real
vcore_entry of the application.  In the future, if we decide to
standardize on the kernel setting up our vcore TLS for us (as it does
for x86_64), then this level of indirection can be avoided.

Although not currenlty utilized, one nice property of this approach (in
addition to removing our reliance on making _start reentrant), is that
different vcore_entry() points can be set up for different vcores,
potentially providing a fast path for critical code running on those
vcores that doesn't need to run through the standard vcore_entry()
sequence.  Such functionality may provie useful in the future.

[brho: moved vcore_entry's in VCPD adjacent to stack and tls_desc, added
comment and __vcore_entry = TRUE in __kernel_vcore_entry() ]
kern/include/ros/event.h
kern/src/process.c
kern/src/trap.c
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/init.c [deleted file]
tools/compilers/gcc-glibc/glibc-2.19-akaros/sysdeps/akaros/x86_64/start.S [deleted file]
user/parlib/vcore.c