vmm: Overhaul how vthread_create works
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 11 Sep 2017 21:56:48 +0000 (17:56 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 14 Sep 2017 20:38:44 +0000 (16:38 -0400)
commit1b85bfd2b56a461902e88266e8abcda46d5d5c9c
tree20b37446159dd440f3f940ab45886eea08e0022a
parent5e0711a60df84a0e8ef3f746d7dda9f09305701c
vmm: Overhaul how vthread_create works

vthread_attr_init() is gone.  That was a vestige of the "let me create the
threads implicitly and then have them ready later."

This splits vthread_create() into several helpers: allocation, context
initialization, and running.  The important part is splitting the
"creation" (allocation, setup, etc) from actually running it.

Some users, like dune, want to do stuff to the context after creating it,
but before creating the thread.  That's a mess.  You shouldn't access the
vm_tf before the thread was created!  We were getting by because we
declared the max number of vthreads in advance.

The old vthread_create() still works, though it returns a pointer to the
thread instead of success/fail.  It's just a convenience wrapper calling
the helpers.  It still takes the gpcid (guest), but that will change
shortly.  I kept the name intact, since it's similar to what people expect
from e.g. pthread_create.

As a side note, it was a bad sign that we didn't have a vthread struct or
header.  We might end up making vthreads more distinct from VMs in the
future.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
tests/dune/dune.c
tests/mmap_file_vmm.c
user/vmm/include/vmm/sched.h
user/vmm/include/vmm/vmm.h
user/vmm/include/vmm/vthread.h [new file with mode: 0644]
user/vmm/vthread.c