tree b851621b73423f52a2338d481d28b62204e46387
parent 1e533a8a863a64e6e871700b8e0b0cfa438615df
author Barret Rhoden <brho@cs.berkeley.edu> 1467827780 -0400
committer Barret Rhoden <brho@cs.berkeley.edu> 1467918302 -0400

Initialize all vcores in SCP mode

Previously, we were initializing vcores on demand.  Now we'll just take
care of them early, before anything crazy goes on.  We still wait until we
know the user wants an MCP before prepping vcores > 0.  The newer style is
a little simpler and a little safer.

The old style could be troublesome since allocating TLS results in a
malloc.  Then we'd be mallocing from any context that could request vcores
- including vcore context.  (e.g. a 2LS wants more vcores in sched_entry).

In general, malloc from vcore context is getting to be a little dangerous,
due to the various locks that could be held by a uthread.  Say a uthread
grabs a malloc lock, but it is preempted.  Then vcore context tries to
malloc, resulting in a deadlock.

One solution is to fix up glibc to use PDR locks - that scenario is what
they are designed for.  There are a couple issues with that for now, and
simply reducing the amount of code that is called from vcore context is
always a good thing.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>