Proc code unmaps vcores when taking cores
[akaros.git] / Documentation / process-internals.txt
1 process-internals.txt
2 Barret Rhoden
3
4 This discusses core issues with process design and implementation.  Most of this
5 info is available in the source in the comments (but may not be in the future).
6 For now, it's a dumping ground for topics that people ought to understand before
7 they muck with how processes work.
8
9 Contents:
10 1. Reference Counting
11 2. When Do We Really Leave "Process Context"?
12 3. Leaving the Kernel Stack
13 4. Preemption and Notification Issues
14 5. current_tf and owning_proc
15 6. Locking!
16 7. TLB Coherency
17 8. Process Management
18 9. TBD
19
20 1. Reference Counting
21 ===========================
22 1.1 Basics:
23 ---------------------------
24 Reference counts exist to keep a process alive.  We use krefs for this, similar
25 to Linux's kref:
26 - Can only incref if the current value is greater than 0, meaning there is
27   already a reference to it.  It is a bug to try to incref on something that has
28   no references, so always make sure you incref something that you know has a
29   reference.  If you don't know, you need to get it from pid2proc (which is a
30   careful way of doing this - pid2proc kref_get_not_zero()s on the reference that is
31   stored inside it).  If you incref and there are 0 references, the kernel will
32   panic.  Fix your bug / don't incref random pointers.
33 - Can always decref.
34 - When the decref returns 0, perform some operation.  This does some final
35   cleanup on the object.
36 - Process code is trickier since we frequently make references from 'current'
37   (which isn't too bad), but also because we often do not return and need to be
38   careful about the references we passed in to a no-return function.
39
40 1.2 Brief History of the Refcnt:
41 ---------------------------
42 Originally, the refcnt was created to keep page tables from being destroyed (in
43 proc_free()) while cores were still using them, which is what was happens during
44 an ARSC (async remote syscall).  It was then defined to be a count of places in
45 the kernel that had an interest in the process staying alive, practically just
46 to protect current/cr3.  This 'interest' actually extends to any code holding a
47 pointer to the proc, such as one acquired via pid2proc(), which is its current
48 meaning.
49
50 1.3 Quick Aside: The current Macro:
51 ---------------------------
52 current is a pointer to the proc that is currently loaded/running on any given
53 core.  It is stored in the per_cpu_info struct, and set/managed by low-level
54 process code.  It is necessary for the kernel to quickly figure out who is
55 running on its core, especially when servicing interrupts and traps.  current is
56 protected by a refcnt.
57
58 current does not say which process owns / will-run on a core.  The per-cpu
59 variable 'owning_proc' covers that.  'owning_proc' should be treated like
60 'current' (aka, 'cur_proc') when it comes to reference counting.  Like all
61 refcnts, you can use it, but you can't consume it without atomically either
62 upping the refcnt or passing the reference (clearing the variable storing the
63 reference).  Don't pass it to a function that will consume it and not return
64 without upping it.
65
66 1.4 Reference Counting Rules:
67 ---------------------------
68 +1 for existing.
69 - The fact that the process is supposed to exist is worth +1.  When it is time
70   to die, we decref, and it will eventually be cleaned up.  This existence is
71   explicitly kref_put()d in proc_destroy().
72 - The hash table is a bit tricky.  We need to kref_get_not_zero() when it is
73   locked, so we know we aren't racing with proc_free freeing the proc and
74   removing it from the list.  After removing it from the hash, we don't need to
75   kref_put it, since it was an internal ref.  The kref (i.e. external) isn't for
76   being on the hash list, it's for existing.  This separation allows us to
77   remove the proc from the hash list in the "release" function.  See kref.txt
78   for more details.
79
80 +1 for someone using it or planning to use it.
81 - This includes simply having a pointer to the proc, since presumably you will
82   use it.  pid2proc() will incref for you.  When you are done, decref.
83 - Functions that create a process and return a pointer (like proc_create() or
84   kfs_proc_create()) will also up the refcnt for you.  Decref when you're done.
85 - If the *proc is stored somewhere where it will be used again, such as in an IO
86   continuation, it needs to be refcnt'd.  Note that if you already had a
87   reference from pid2proc(), simply don't decref after you store the pointer.
88
89 +1 for current.
90 - current counts as someone using it (expressing interest in the core), but is
91   also a source of the pointer, so its a bit different.  Note that all kref's
92   are sources of a pointer.  When we are running on a core that has current
93   loaded, the ref is both for its usage as well as for being the current
94   process.
95 - You have a reference from current and can use it without refcnting, but
96   anything that needs to eat a reference or store/use it needs an incref first.
97   To be clear, your reference is *NOT* edible.  It protects the cr3, guarantees
98   the process won't die, and serves as a bootstrappable reference.
99 - Specifically, if you get a ref from current, but then save it somewhere (like
100   an IO continuation request), then clearly you must incref, since it's both
101   current and stored/used.
102 - If you don't know what might be downstream from your function, then incref
103   before passing the reference, and decref when it returns.  We used to do this
104   for all syscalls, but now only do it for calls that might not return and
105   expect to receive reference (like proc_yield).
106
107 All functions that take a *proc have a refcnt'd reference, though it may not be
108 edible (it could be current).  It is the callers responsibility to make sure
109 it'd edible if it necessary.  It is the callees responsibility to incref if it
110 stores or makes a copy of the reference.
111
112 1.5 Functions That Don't or Might Not Return:
113 ---------------------------
114 Refcnting and especially decreffing gets tricky when there are functions that
115 MAY not return.  proc_restartcore() does not return (it pops into userspace).
116 proc_run() used to not return, if the core it was called on would pop into
117 userspace (if it was a _S, or if the core is part of the vcoremap for a _M).
118 This doesn't happen anymore, since we have cur_tf in the per-cpu info.
119
120 Functions that MAY not return will "eat" your reference *IF* they do not return.
121 This means that you must have a reference when you call them (like always), and
122 that reference will be consumed / decref'd for you if the function doesn't
123 return.  Or something similarly appropriate.
124
125 Arguably, for functions that MAY not return, but will always be called with
126 current's reference (proc_yield()), we could get away without giving it an
127 edible reference, and then never eating the ref.  Yield needs to be reworked
128 anyway, so it's not a bit deal yet.
129
130 We do this because when the function does not return, you will not have the
131 chance to decref (your decref code will never run).  We need the reference when
132 going in to keep the object alive (like with any other refcnt).  We can't have
133 the function always eat the reference, since you cannot simply re-incref the
134 pointer (not allowed to incref unless you know you had a good reference).  You'd
135 have to do something like p = pid2proc(p_pid);  It's clunky to do that, easy to
136 screw up, and semantically, if the function returns, then we may still have an
137 interest in p and should decref later.
138
139 The downside is that functions need to determine if they will return or not,
140 which can be a pain (for an out-of-date example: a linear time search when
141 running an _M, for instance, which can suck if we are trying to use a
142 broadcast/logical IPI).
143
144 As the caller, you usually won't know if the function will return or not, so you
145 need to provide a consumable reference.  Current doesn't count.  For example,
146 proc_run() requires a reference.  You can proc_run(p), and use p afterwards, and
147 later decref.  You need to make sure you have a reference, so things like
148 proc_run(pid2proc(55)) works, since pid2proc() increfs for you.  But you cannot
149 proc_run(current), unless you incref current in advance.  Incidentally,
150 proc_running current doesn't make a lot of sense.
151
152 1.6 Runnable List:
153 ---------------------------
154 Procs on the runnable list need to have a refcnt (other than the +1 for
155 existing).  It's something that cares that the process exists.  We could have
156 had it implicitly be refcnt'd (the fact that it's on the list is enough, sort of
157 as if it was part of the +1 for existing), but that complicates things.  For
158 instance, it is a source of a reference (for the scheduler) and you could not
159 proc_run() a process from the runnable list without worrying about increfing it
160 before hand.  This isn't true anymore, but the runnable lists are getting
161 overhauled anyway.  We'll see what works nicely.
162
163 1.7 Internal Details for Specific Functions:
164 ---------------------------
165 proc_run()/__proc_give_cores(): makes sure enough refcnts are in place for all
166 places that will install owning_proc.  This also makes it easier on the system
167 (one big incref(n), instead of n increfs of (1) from multiple cores). 
168
169 __set_proc_current() is a helper that makes sure p is the cur_proc.  It will
170 incref if installing a new reference to p.  If it removed an old proc, it will
171 decref.
172
173 __proc_startcore(): assumes all references to p are sorted.  It will not
174 return, and you should not pass it a reference you need to decref().  Passing
175 it 'owning_proc' works, since you don't want to decref owning_proc.
176
177 proc_destroy(): it used to not return, and back then if your reference was
178 from 'current', you needed to incref.  Now that proc_destroy() returns, it
179 isn't a big deal.  Just keep in mind that if you have a function that doesn't
180 return, there's no way for the function to know if it's passed reference is
181 edible.  Even if p == current, proc_destroy() can't tell if you sent it p (and
182 had a reference) or current and didn't.
183
184 proc_yield(): when this doesn't return, it eats your reference.  It will also
185 decref twice.  Once when it clears_owning_proc, and again when it calls
186 abandon_core() (which clears cur_proc).
187
188 abandon_core(): it was not given a reference, so it doesn't eat one.  It will
189 decref when it unloads the cr3.  Note that this is a potential performance
190 issue.  When preempting or killing, there are n cores that are fighting for the
191 cacheline to decref.  An alternative would be to have one core decref for all n
192 cores, after it knows all cores unloaded the cr3.  This would be a good use of
193 the checklist (possibly with one cacheline per core).  It would take a large
194 amount of memory for better scalability.
195
196 1.8 Things I Could Have Done But Didn't And Why:
197 ---------------------------
198 Q: Could we have the first reference (existence) mean it could be on the runnable
199 list or otherwise in the proc system (but not other subsystems)?  In this case,
200 proc_run() won't need to eat a reference at all - it will just incref for every
201 current it will set up.
202
203 New A: Maybe, now that proc_run() returns.
204
205 Old A: No: if you pid2proc(), then proc_run() but never return, you have (and
206 lose) an extra reference.  We need proc_run() to eat the reference when it
207 does not return.  If you decref between pid2proc() and proc_run(), there's a
208 (rare) race where the refcnt hits 0 by someone else trying to kill it.  While
209 proc_run() will check to see if someone else is trying to kill it, there's a
210 slight chance that the struct will be reused and recreated.  It'll probably
211 never happen, but it could, and out of principle we shouldn't be referencing
212 memory after it's been deallocated.  Avoiding races like this is one of the
213 reasons for our refcnt discipline.
214
215 Q: (Moot) Could proc_run() always eat your reference, which would make it
216 easier for its implementation?
217
218 A: Yeah, technically, but it'd be a pain, as mentioned above.  You'd need to
219 reaquire a reference via pid2proc, and is rather easy to mess up.
220
221 Q: (Moot) Could we have made proc_destroy() take a flag, saying whether or not
222 it was called on current and needed a decref instead of wasting an incref?
223
224 A: We could, but won't.  This is one case where the external caller is the one
225 that knows the function needs to decref or not.  But it breaks the convention a
226 bit, doesn't mirror proc_create() as well, and we need to pull in the cacheline
227 with the refcnt anyways.  So for now, no.
228
229 Q: (Moot) Could we make __proc_give_cores() simply not return if an IPI is
230 coming?
231
232 A: I did this originally, and manually unlocked and __wait_for_ipi()d.  Though
233 we'd then need to deal with it like that for all of the related functions, which
234 doesn't work if you wanted to do something afterwards (like schedule(p)).  Also
235 these functions are meant to be internal helpers, so returning the bool makes
236 more sense.  It eventually led to having __proc_unlock_ipi_pending(), which made
237 proc_destroy() much cleaner and helped with a general model of dealing with
238 these issues.  Win-win.
239
240 2. When Do We Really Leave "Process Context"?
241 ===========================
242 2.1 Overview
243 ---------------------------
244 First off, it's not really "process context" in the way Linux deals with it.  We
245 aren't operating in kernel mode on behalf of the process (always).  We are
246 specifically talking about when a process's cr3 is loaded on a core.  Usually,
247 current is also set (the exception for now is when processing ARSCs).
248
249 There are a couple different ways to do this.  One is to never unload a context
250 until something new is being run there (handled solely in __proc_startcore()).
251 Another way is to always explicitly leave the core, like by abandon_core()ing.
252
253 The issue with the former is that you could have contexts sitting around for a
254 while, and also would have a bit of extra latency when __proc_free()ing during
255 someone *else's* __proc_startcore() (though that could be avoided if it becomes
256 a real issue, via some form of reaping).  You'll also probably have excessive
257 decrefs (based on the interactions between proc_run() and __startcore()).
258
259 The issue with the latter is excessive TLB shootdowns and corner cases.  There
260 could be some weird cases (in core_request() for example) where the core you are
261 running on has the context loaded for proc A on a mgmt core, but decides to give
262 it to proc B.
263
264 If no process is running there, current == 0 and boot_cr3 is loaded, meaning no
265 process's context is loaded.
266
267 All changes to cur_proc, owning_proc, and cur_tf need to be done with
268 interrupts disabled, since they change in interrupt handlers.
269
270 2.2 Here's how it is done now:
271 ---------------------------
272 All code is capable of 'spamming' cur_proc (with interrupts disabled!).  If it
273 is 0, feel free to set it to whatever process you want.  All code that
274 requires current to be set will do so (like __proc_startcore()).  The
275 smp_idle() path will make sure current is clear when it halts.  So long as you
276 don't change other concurrent code's expectations, you're okay.  What I mean
277 by that is you don't clear cur_proc while in an interrupt handler.  But if it
278 is already 0, __startcore is allowed to set it to it's future proc (which is
279 an optimization).  Other code didn't have any expectations of it (it was 0).
280 Likewise, kthread code when we sleep_on() doesn't have to keep cur_proc set.
281 A kthread is somewhat an isolated block (codewise), and leaving current set
282 when it is done is solely to avoid a TLB flush (at the cost of an incref).
283
284 In general, we try to proactively leave process context, but have the ability
285 to stay in context til __proc_startcore() to handle the corner cases (and to
286 maybe cut down the TLB flushes later).  To stop proactively leaving, just
287 change abandon_core() to not do anything with current/cr3.  You'll see weird
288 things like processes that won't die until their old cores are reused.  The
289 reason we proactively leave context is to help with sanity for these issues,
290 and also to avoid decref's in __startcore().
291
292 A couple other details: __startcore() sorts the extra increfs, and
293 __proc_startcore() sorts leaving the old context.  Anytime a __startcore kernel
294 message is sent, the sender increfs in advance for the owning_proc refcnt.  As
295 an optimization, we can also incref to *attempt* to set current.  If current
296 was 0, we set it.  If it was already something else, we failed and need to
297 decref.  __proc_startcore(), which the last moment before we *must* have the
298 cr3/current issues sorted, does the actual check if there was an old process
299 there or not, while it handles the lcr3 (if necessary).  In general, lcr3's
300 ought to have refcnts near them, or else comments explaining why not.
301
302 So we leave process context when told to do so (__death/abandon_core()) or if
303 another process is run there.  The _M code is such that a proc will stay on its
304 core until it receives a message, and that message would cleanup/restore a
305 generic context (boot_cr3).  A _S could stay on its core until another _S came
306 in.  This is much simpler for cases when a timer interrupt goes off to force a
307 schedule() decision.  It also avoids a TLB flush in case the scheduler picked
308 that same proc to run again.  This could also happen to an _M, if for some
309 reason it was given a management core (!!!) or some other event happened that
310 caused some management/scheduling function to run on one of it's cores (perhaps
311 it asked).
312
313 proc_yield() abandons the core / leaves context.
314
315 2.3 Other issues:
316 ---------------------------
317 Note that dealing with interrupting processes that are in the kernel is tricky.
318 There is no true process context, so we can't leave a core until the kernel is
319 in a "safe place", i.e. it's state is bundled enough that it can be recontinued
320 later.  Calls of this type are routine kernel messages, executed at a convenient
321 time (specifically, before we return to userspace in proc_restartcore().
322
323 This same thing applies to __death messages.  Even though a process is dying, it
324 doesn't mean we can just drop whatever the kernel was doing on its behalf.  For
325 instance, it might be holding a reference that will never get decreffed if its
326 stack gets dropped.
327
328 3. Leaving the Kernel Stack:
329 ===========================
330 Just because a message comes in saying to kill a process, it does not mean we
331 should immediately abandon_core().  The problem is more obvious when there is
332 a preempt message, instead of a death message, but either way there is state
333 that needs cleaned up (refcnts that need downed, etc).
334
335 The solution to this is rather simple: don't abandon right away.  That was
336 always somewhat the plan for preemption, but was never done for death.  And
337 there are several other cases to worry about too.  To enforce this, we expand
338 the old "active messages" into a generic work execution message (a kernel
339 message) that can be delayed or shipped to another core.  These types of
340 messages will not be executed immediately on the receiving pcore - instead they
341 are on the queue for "when there's nothing else to do in the kernel", which is
342 checked in smp_idle() and before returning to userspace in proc_restartcore().
343 Additionally, these kernel messages can also be queued on an alarm queue,
344 delaying their activation as part of a generic kernel alarm facility.
345
346 One subtlety is that __proc_startcore() shouldn't check for messages, since it
347 is called by __startcore (a message).  Checking there would run the messages out
348 of order, which is exactly what we are trying to avoid (total chaos).  No one
349 should call __proc_startcore, other than proc_restartcore() or __startcore().
350 If we ever have functions that do so, if they are not called from a message,
351 they must check for outstanding messages.
352
353 This last subtlety is why we needed to change proc_run()'s _S case to use a
354 local message instead of calling proc_starcore (and why no one should ever call
355 proc_startcore()).  We could unlock, thereby freeing another core to change the
356 proc state and send a message to us, then try to proc_startcore, and then
357 reading the message before we had installed current or had a userspace TF to
358 preempt, and probably a few other things.  Treating _S as a local message is
359 cleaner, begs to be merged in the code with _M's code, and uses the messaging
360 infrastructure to avoid all the races that it was created to handle.
361
362 Incidentally, we don't need to worry about missing messages while trying to pop
363 back to userspace from __proc_startcore, since an IPI will be on the way
364 (possibly a self-ipi caused by the __kernel_message() handler).  This is also
365 why we needed to make process_routine_kmsg() keep interrupts disabled when it
366 stops (there's a race between checking the queue and disabling ints).
367
368 4. Preemption and Notification Issues:
369 ===========================
370 4.1: Message Ordering and Local Calls:
371 ---------------------------
372 Since we go with the model of cores being told what to do, there are issues
373 with messages being received in the wrong order.  That is why we have the
374 kernel messages (guaranteed, in-order delivery), with the proc-lock protecting
375 the send order.  However, this is not enough for some rare races.
376
377 Local calls can also perform the same tasks as messages (calling
378 proc_destroy() while a death IPI is on its way). We refer to these calls as
379 messing with "local fate" (compared to global state (we're clever).
380 Preempting a single vcore doesn't change the process's state).  These calls
381 are a little different, because they also involve a check to see if it should
382 perform the function or other action (e.g., death just idling and waiting for
383 an IPI instead of trying to kill itself), instead of just blindly doing
384 something.
385
386 4.1.1: Possible Solutions
387 ----------------
388 There are two ways to deal with this.  One (and the better one, I think) is to
389 check state, and determine if it should proceed or abort.  This requires that
390 all local-fate dependent calls always have enough state to do its job.  In the
391 past, this meant that any function that results in sending a directive to a
392 vcore store enough info in the proc struct that a local call can determine if
393 it should take action or abort.  In the past, we used the vcore/pcoremap as a
394 way to send info to the receiver about what vcore they are (or should be).
395 Now, we store that info in pcpui (for '__startcore', we send it as a
396 parameter.  Either way, the general idea is still true: local calls can
397 proceed when they are called, and not self-ipi'd to a nebulous later time.
398
399 The other way is to send the work (including the checks) in a self-ipi kernel
400 message.  This will guarantee that the message is executed after any existing
401 messages (making the k_msg queue the authority for what should happen to a
402 core).  The check is also performed later (when the k_msg executes).  There
403 are a couple issues with this: if we allow the local core to send itself an
404 k_msg that could be out of order (meaning it should not be sent, and is only
405 sent due to ignorance of its sealed fate), AND if we return the core to the
406 idle-core-list once its fate is sealed, we need to detect that the message is
407 for the wrong process and that the process is in the wrong state.  To do this,
408 we probably need local versioning on the pcore so it can detect that the
409 message is late/wrong.  We might get by with just the proc* (though that is
410 tricky with death and proc reuse), so long as we don't allow new startcores
411 for a proc until AFTER the preemption is completed.
412
413 4.2: Preempt-Served Flag
414 ----------------
415 We want to be able to consider a pcore free once its owning proc has dealt
416 with removing it.  This allows a scheduler-like function to easily take a core
417 and then give it to someone else, without waiting for each vcore to respond,
418 saying that the pcore is free/idle.
419
420 We used to not unmap until we were in '__preempt' or '__death', and we needed
421 a flag to tell yield-like calls that a message was already on the way and to
422 not rely on the vcoremap.  This is pretty fucked up for a number of reasons,
423 so we changed that.  But we still wanted to know when a preempt was in
424 progress so that the kernel could avoid giving out the vcore until the preempt
425 was complete.
426
427 Here's the scenario: we send a '__startcore' to core 3 for VC5->PC3.  Then we
428 quickly send a '__preempt' to 3, and then a '__startcore' to core 4 (a
429 different pcore) for VC5->PC4.  Imagine all of this happens before the first
430 '__startcore' gets processed (IRQ delay, fast ksched, whatever).  We need to
431 not run the second '__startcore' on pcore 4 before the preemption has saved
432 all of the state of the VC5.  So we spin on preempt_served (which may get
433 renamed to preempt_in_progress).  We need to do this in the sender, and not
434 the receiver (not in the kmsg), because the kmsgs can't tell which one they
435 are.  Specifically, the first '__startcore' on core 3 runs the same code as
436 the '__startcore' on core 4, working on the same vcore.  Anything we tell VC5
437 will be seen by both PC3 and PC4.  We'd end up deadlocking on PC3 while it
438 spins waiting for the preempt message that also needs to run on PC3.
439
440 The preempt_pending flag is actual a timestamp, with the expiration time of
441 the core at which the message will be sent.  We could try to use that, but
442 since alarms aren't fired at exactly the time they are scheduled, the message
443 might not actually be sent yet (though it will, really soon).  Still, we'll
444 just go with the preempt-served flag for now.
445
446 4.3: Impending Notifications
447 ----------------
448 It's also possible that there is an impending notification.  There's no change
449 in fate (though there could be a fate-changing preempt on its way), just the
450 user wants a notification handler to run.  We need a flag anyways for this
451 (discussed below), so proc_yield() or whatever other local call we have can
452 check this flag as well.  
453
454 Though for proc_yield(), it doesn't care if a notification is on its way (can
455 be dependent on a flag to yield from userspace, based on the nature of the
456 yield (which still needs to be sorted)).  If the yield is in response to a
457 preempt_pending, it actually should yield and not receive the notification.
458 So it should destroy its vcoreid->pcoreid mapping and abandon_core().  When
459 that notification hits, it will be for a proc that isn't current, and will be
460 ignored (it will get run the next time that vcore fires up, handled below).
461
462 There is a slight chance that the same proc will run on that pcore, but with a
463 different vcoreid.  In the off chance this happens, the new vcore will get a
464 spurious notification.  Userspace needs to be able to handle spurious
465 notifications anyways, (there are a couple other cases, and in general it's
466 not hard to do), so this is not a problem.  Instead of trying to have the
467 kernel ignore the notification, we just send a spurious one.  A crappy
468 alternative would be to send the vcoreid with the notification, but that would
469 mean we can't send a generic message (broadcast) to a bunch of cores, which
470 will probably be a problem later.
471
472 Note that this specific case is because the "local work message" gets
473 processed out of order with respect to the notification.  And we want this in
474 that case, since that proc_yield() is more important than the notification.
475
476 4.4: Preemption / Allocation Phases and Alarm Delays
477 ---------------------------
478 A per-vcore preemption phase starts when the kernel marks the core's
479 preempt_pending flag/counter and can includes the time when an alarm is
480 waiting to go off to reclaim the core.  The phase ends when the vcore's pcore
481 is reclaimed, either as a result of the kernel taking control, or because a
482 process voluntarily yielded.
483
484 Specifically, the preempt_pending variable is actually a timestamp for when
485 the core will be revoked (this assumes some form of global time, which we need
486 anyways).  If its value is 0, then there is no preempt-pending, it is not in a
487 phase, and the vcore can be given out again. 
488
489 When a preempt alarm goes off, the alarm only means to check a process for
490 expired vcores.  If the vcore has been yielded while the alarm was pending,
491 the preempt_pending flag will be reset to 0.  To speed up the search for
492 vcores to preempt, there's a circular buffer corelist in the proc struct, with
493 vcoreids of potential suspects.  Or at least this will exist at some point.
494 Also note that the preemption list isn't bound to a specific alarm: you can
495 check the list at any time (not necessarily on a specific alarm), and you can
496 have spurious alarms (the list is empty, so it'll be a noop).
497
498 Likewise, a global preemption phase is when an entire MCP is getting
499 gang_prempted, and the global deadline is set.  A function can quickly check
500 to see if the process responded, since the list of vcores with preemptions
501 pending will be empty.
502
503 It seems obvious, but we do not allow allocation of a vcore during its
504 preemption phase.  The main reason is that it can potentially break
505 assumptions about the vcore->pcore mapping and can result in multiple
506 instances of the same vcore on different pcores.  Imagine a preempt message
507 sent to a pcore (after the alarm goes off), meanwhile that vcore/pcore yields
508 and the vcore reactivates somewhere else.  There is a potential race on the
509 preempt_tf state: the new vcore is reading while the old is writing.  This
510 issue is sorted naturally: the vcore entry in the vcoremap isn't cleared until
511 the vcore/pcore is actually yielded/taken away, so the code looking for a free
512 vcoreid slot will not try to use it.
513
514 Note that if we didn't design the alarm system to simply check for
515 preemptions (perhaps it has a stored list of vcores to preempt), then we
516 couldn't end the preempt-phase until the alarm was sorted.  If that is the
517 case, we could easily give out a vcore that had been yielded but was still in
518 a preempt-phase.  Stopping an alarm would be tricky too, since there could be
519 lots of vcores in different states that need to be sorted by the alarm (so
520 ripping it out isn't enough).  Setting a flag might not be enough either.
521 Vcore version numbers/history (as well as global proc histories) is a pain I'd
522 like to avoid too.  So don't change the alarm / delayed preemption system
523 without thinking about this.
524
525 Also, allowing a vcore to restart while preemptions are pending also mucks
526 with keeping the vcore mapping "old" (while the message is in flight).  A
527 pcore will want to use that to determine which vcore is running on it.  It
528 would be possible to keep a pcoremap for the reverse mapping out of sync, but
529 that seems like a bad idea.  In general, having the pcoremap is a good idea
530 (whenever we talk about a vcoremap, we're usually talking about both
531 directions: "the vcore->pcore mapping").
532
533 4.5: Global Preemption Flags
534 ---------------------------
535 If we are trying to preempt an entire process at the same time, instead of
536 playing with the circular buffer of vcores pending preemption, we could have a
537 global timer as well.  This avoids some O(n) operations, though it means that
538 userspace needs to check two "flags" (expiration dates) when grabbing its
539 preempt-critical locks.
540
541 4.6: Notifications Mixed with Preemption and Sleeping
542 ---------------------------
543 It is possible that notifications will mix with preemptions or come while a
544 process is not running.  Ultimately, the process wants to be notified on a
545 given vcore.  Whenever we send an active notification, we set a flag in procdata
546 (notif_pending).  If the vcore is offline, we don't bother sending the IPI/notif
547 message.  The kernel will make sure it runs the notification handler (as well as
548 restoring the preempt_tf) the next time that vcore is restarted.  Note that
549 userspace can toggle this, so they can handle the notifications from a different
550 core if it likes, or they can independently send a notification.
551
552 Note we use notif_pending to detect if an IPI was missed while notifs were
553 disabled (this is done in pop_ros_tf() by userspace).  The overall meaning of
554 notif_pending is that a vcore wants to be IPI'd.  The IPI could be in-flight, or
555 it could be missed.  Since notification IPIs can be spurious, when we have
556 potential races, we err on the side of sending.  This happens when pop_ros_tf()
557 notifies itself, and when the kernel starts a vcore in it's notif handler if it
558 was preempted and notif was pending.  In the latter case, the kernel will put
559 the preempt_tf in the notif_tf, so userspace can restart that at its leisure.
560
561 If a vcore has a preempt_pending, we will still send the active notification
562 (IPI).  The core ought to get a notification for the preemption anyway, so we
563 need to be able to send one.  Additionally, once the vcore is handling that
564 preemption notification, it will have notifs disabled, which will prevent us
565 from sending any extra notifications anyways.
566  
567 4.7: Notifs While a Preempt Message is Served
568 ---------------------------
569 It is possible to have the kernel handling a notification k_msg and to have a
570 preempt k_msg in the queue (preempt-served flag is set).  Ultimately, what we
571 want is for the core to be preempted and the notification handler to run on
572 the next execution.  Both messages are in the k_msg queue for "a convenient
573 time to leave the kernel" (I'll have a better name for that later).  What we
574 do is execute the notification handler and jump to userspace.  Since there is
575 still an k_msg in the queue (and we self_ipi'd ourselves, it's part of how
576 k_msgs work), the IPI will fire and push us right back into the kernel to
577 execute the preemption, and the notif handler's context will be saved in the
578 preempt_tf (ready to go when the vcore gets started again).
579
580 We could try to just leave the notif_pending flag set and ignore the message,
581 but that would involve inspecting the queue for the preempt k_msg.
582 Additionally, a preempt k_msg can arrive anyway.  Finally, it's possible to have
583 another message in the queue between the notif and the preempt, and it gets ugly
584 quickly trying to determine what to do.
585
586 4.8: When a Pcore is "Free"
587 ---------------------------
588 There are a couple ways to handle pcores.  One approach would be to not
589 consider them free and able to be given to another process until the old
590 process is completely removed (abandon_core()).  Another approach is to free
591 the core once its fate is sealed (which we do).  This probably gives more
592 flexibility in schedule()-like functions (no need to wait to give the core
593 out), quicker dispatch latencies, less contention on shared structs (like the
594 idle-core-map), etc.
595
596 This 'freeing' of the pcore is from the perspective of the kernel scheduler
597 and the proc struct.  Contrary to all previous announcements, vcores are
598 unmapped from pcores when sending k_msgs (technically right after), while
599 holding the lock.  The pcore isn't actually not-running-the-proc until the
600 kmsg completes and we abandon_core().  Previously, we used the vcoremap to
601 communicate to other cores in a lock-free manner, but that was pretty shitty
602 and now we just store the vcoreid in pcpu info.
603
604 Another tricky part is the seq_ctr used to signal userspace of changes to the
605 coremap or num_vcores (coremap_seqctr).  While we may not even need this in the
606 long run, it still seems like it could be useful.  The trickiness comes from
607 when we update the seq_ctr when we are unmapping vcores on the receive side of a
608 message (like __death or __preempt).  We'd rather not have each pcore contend on
609 the seq_ctr cache line (let alone any locking) while they perform a somewhat
610 data-parallel task.  So we continue to have the sending core handle the seq_ctr
611 upping and downing.  This works, since the "unlocking" happens after messages
612 are sent, which means the receiving core is no longer in userspace (if there is
613 a delay, it is because the remote core is in the kernel, possibly with
614 interrupts disabled).  Because of this, userspace will be unable to read the new
615 value of the seq_ctr before the IPI hits and does the unmapping that the seq_ctr
616 protects/advertises.  This is most likely true.  It wouldn't be if the "last IPI
617 was sent" flag clears before the IPI actually hit the other core.
618
619 4.9: Future Broadcast/Messaging Needs
620 ---------------------------
621 Currently, messaging is serialized.  Broadcast IPIs exist, but the kernel
622 message system is based on adding an k_msg to a list in a pcore's
623 per_cpu_info.  Further the sending of these messages is in a loop.  In the
624 future, we would like to have broadcast messaging of some sort (literally a
625 broadcast, like the IPIs, and if not that, then a communication tree of
626 sorts).  
627
628 In the past, (OLD INFO): given those desires, we wanted to make sure that no
629 message we send needs details specific to a pcore (such as the vcoreid running
630 on it, a history number, or anything like that).  Thus no k_msg related to
631 process management would have anything that cannot apply to the entire
632 process.  At this point, most just have a struct proc *.  A pcore was be able
633 to figure out what is happening based on the pcoremap, information in the
634 struct proc, and in the preempt struct in procdata.
635
636 In more recent revisions, the coremap no longer is meant to be used across
637 kmsgs, so some messages ('__startcore') send the vcoreid.  This means we can't
638 easily broadcast the message.  However, many broadcast mechanisms wouldn't
639 handle '__startcore' naturally.  For instance, logical IPIs need something
640 already set in the LAPIC, or maybe need to be sent to a somewhat predetermined
641 group (again, bits in the LAPIC).  If we tried this for '__startcore', we
642 could add something in to the messaging to carry these vcoreids.  More likely,
643 we'll have a broadcast tree.  Keeping vcoreid (or any arg) next to whoever
644 needs to receive the message is a very small amount of bookkeeping on a struct
645 that already does bookkeeping.
646
647 4.10: Other Things We Thought of but Don't Like
648 ---------------------------
649 All local fate-related work is sent as a self k_msg, to enforce ordering.
650 It doesn't capture the difference between a local call and a remote k_msg.
651 The k_msg has already considered state and made its decision.  The local call
652 is an attempt.  It is also unnecessary, if we put in enough information to
653 make a decision in the proc struct.  Finally, it caused a few other problems
654 (like needing to detect arbitrary stale messages).
655
656 Overall message history: doesn't work well when you do per-core stuff, since
657 it will invalidate other messages for the process.  We then though of a pcore
658 history counter to detect stale messages.  Don't like that either.  We'd have
659 to send the history in the message, since it's a per-message, per-core
660 expiration.  There might be other ways around this, but this doesn't seem
661 necessary.
662
663 Alarms have pointers to a list of which cores should be preempted when that
664 specific alarm goes off (saved with the alarm).  Ugh.  It gets ugly with
665 multiple outstanding preemptions and cores getting yielded while the alarms
666 sleep (and possibly could get reallocated, though we'd make a rule to prevent
667 that).  Like with notifications, being able to handle spurious alarms and
668 thinking of an alarm as just a prod to check somewhere is much more flexible
669 and simple.  It is similar to generic messages that have the actual important
670 information stored somewhere else (as with allowing broadcasts, with different
671 receivers performing slightly different operations).
672
673 Synchrony for messages (wanting a response to a preempt k_msg, for example)
674 sucks.  Just encode the state of impending fate in the proc struct, where it
675 belongs.  Additionally, we don't want to hold the proc lock even longer than
676 we do now (which is probably too long as it is).  Finally, it breaks a golden
677 rule: never wait while holding a lock: you will deadlock the system (e.g. if
678 the receiver is already in the kernel spinning on the lock).  We'd have to
679 send messages, unlock (which might cause a message to hit the calling pcore,
680 as in the case of locally called proc_destroy()), and in the meantime some
681 useful invariant might be broken.
682
683 We also considered using the transition stack as a signal that a process is in
684 a notification handler.  The kernel can inspect the stack pointer to determine
685 this.  It's possible, but unnecessary.
686
687 Using the pcoremap as a way to pass info with kmsgs: it worked a little, but
688 had some serious problems, as well as making life difficult.  It had two
689 purposes: help with local fate calls (yield) and allow broadcast messaging.
690 The main issue is that it was using a global struct to pass info with
691 messages, but it was based on the snapshot of state at the time the message
692 was sent.  When you send a bunch of messages, certain state may have changed
693 between messages, and the old snapshot isn't there anymore by the time the
694 message gets there.  To avoid this, we went through some hoops and had some
695 fragile code that would use other signals to avoid those scenarios where the
696 global state change would send the wrong message.  It was tough to understand,
697 and not clear it was correct (hint: it wasn't).  Here's an example (on one
698 pcore): if we send a preempt and we then try to map that pcore to another
699 vcore in the same process before the preempt call checks its pcoremap, we'll
700 clobber the pcore->vcore mapping (used by startcore) and the preempt will
701 think it is the new vcore, not the one it was when the message was sent.
702 While this is a bit convoluted, I can imagine a ksched doing this, and
703 perhaps with weird IRQ delays, the messages might get delayed enough for it to
704 happen.  I'd rather not have to have the ksched worry about this just because
705 proc code was old and ghetto.  Another reason we changed all of this was so
706 that you could trust the vcoremap while holding the lock.  Otherwise, it's
707 actually non-trivial to know the state of a vcore (need to check a combination
708 of preempt_served and is_mapped), and even if you do that, there are some
709 complications with doing this in the ksched.
710
711 5. current_tf and owning_proc
712 ===========================
713 Originally, current_tf is a per-core macro that returns a struct trapframe *
714 that points back on the kernel stack to the user context that was running on
715 the given core when an interrupt or trap happened.  Saving the reference to
716 the TF helps simplify code that needs to do something with the TF (like save
717 it and pop another TF).  This way, we don't need to pass the context all over
718 the place, especially through code that might not care.
719
720 Now, current_tf is more broadly defined as the user context that should be run
721 when the kernel is ready to run a process.  In the older case, it was when the
722 kernel tries to return to userspace from a trap/interrupt.  Now, current_tf
723 can be set by an IPI/KMSG (like '__startcore') so that when the kernel wants
724 to idle, it will find a cur_tf that it needs to run, even though we never
725 trapped in on that context in the first place.
726
727 Further, we now have 'owning_proc', which tells the kernel which process
728 should be run.  'owning_proc' is a bigger deal than 'current_tf', and it is
729 what tells us to run cur_tf.
730
731 Process management KMSGs now simply modify 'owning_proc' and cur_tf, as if we
732 had interrupted a process.  Instead of '__startcore' forcing the kernel to
733 actually run the process and trapframe, it will just mean we will eventually
734 run it.  In the meantime a '__notify' or a '__preempt' can come in, and they
735 will apply to the owning_proc/cur_tf.  This greatly simplifies process code
736 and code calling process code (like the scheduler), since we no longer need to
737 worry about whether or not we are getting a "stack killing" kernel message.
738 Before this, code needed to care where it was running when managing _Ms.
739
740 Note that neither 'current_tf' nor 'owning_proc' rely on 'current'/'cur_proc'.
741 'current' is just what process context we're in, not what process (and which
742 trapframe) we will eventually run.
743
744 cur_tf does not point to kernel trapframes, which is important when we receive an
745 interrupt in the kernel.  At one point, we were (hypothetically) clobbering the
746 reference to the user trapframe, and were unable to recover.  We can get away
747 with this because the kernel always returns to its previous context from a
748 nested handler (via iret on x86).  
749
750 In the future, we may need to save kernel contexts and may not always return via
751 iret.  At which point, if the code path is deep enough that we don't want to
752 carry the TF pointer, we may revisit this.  Until then, current_tf is just for
753 userspace contexts, and is simply stored in per_cpu_info.
754
755 6. Locking!
756 ===========================
757 6.1: proc_lock
758 ---------------------------
759 Currently, all locking is done on the proc_lock.  It's main goal is to protect
760 the vcore mapping (vcore->pcore and vice versa).  As of Apr 2010, it's also used
761 to protect changes to the address space and the refcnt.  Eventually the refcnt
762 will be handled with atomics, and the address space will have it's own MM lock.  
763
764 We grab the proc_lock all over the place, but we try to avoid it whereever
765 possible - especially in kernel messages or other places that will be executed
766 in parallel.  One place we do grab it but would like to not is in proc_yield().  
767 We don't always need to grab the proc lock.  Here are some examples:
768
769 6.1.1: Lockless Notifications:
770 -------------
771 We don't lock when sending a notification.  We want the proc_lock to not be an
772 irqsave lock (discussed below).  Since we might want to send a notification from
773 interrupt context, we can't grab the proc_lock if it's a regular lock.  
774
775 This is okay, since the proc_lock is only protecting the vcoremapping.  We could
776 accidentally send the notification to the wrong pcore.  The __notif handler
777 checks to make sure it is the right process, and all _M processes should be able
778 to handle spurious notifications.  This assumes they are still _M.
779
780 If we send it to the wrong pcore, there is a danger of losing the notif, since
781 it didn't go to the correct vcore.  That would happen anyway, (the vcore is
782 unmapped, or in the process of mapping).  The notif_pending flag will be caught
783 when the vcore is started up next time (and that flag was set before reading the
784 vcoremap).
785
786 6.1.2: Local get_vcoreid():
787 -------------
788 It's not necessary to lock while checking the vcoremap if you are checking for
789 the core you are running on (e.g. pcoreid == core_id()).  This is because all
790 unmappings of a vcore are done on the receive side of a routine kmsg, and that
791 code cannot run concurrently with the code you are running.  
792
793 6.2: irqsave
794 ---------------------------
795 The proc_lock used to be an irqsave lock (meaning it disables interrupts and can
796 be grabbed from interrupt context).  We made it a regular lock for a couple
797 reasons.  The immediate one was it was causing deadlocks due to some other
798 ghetto things (blocking on the frontend server, for instance).  More generally,
799 we don't want to disable interrupts for long periods of time, so it was
800 something worth doing anyway.  
801
802 This means that we cannot grab the proc_lock from interrupt context.  This
803 includes having schedule called from an interrupt handler (like the
804 timer_interrupt() handler), since it will call proc_run.  Right now, we actually
805 do this, which we shouldn't, and that will eventually get fixed.  The right
806 answer is that the actual work of running the scheduler should be a routine
807 kmsg, similar to how Linux sets a bit in the kernel that it checks on the way
808 out to see if it should run the scheduler or not.
809
810 7. TLB Coherency
811 ===========================
812 When changing or removing memory mappings, we need to do some form of a TLB
813 shootdown.  Normally, this will require sending an IPI (immediate kmsg) to
814 every vcore of a process to unmap the affected page.  Before allocating that
815 page back out, we need to make sure that every TLB has been flushed.  
816
817 One reason to use a kmsg over a simple handler is that we often want to pass a
818 virtual address to flush for those architectures (like x86) that can
819 invalidate a specific page.  Ideally, we'd use a broadcast kmsg (doesn't exist
820 yet), though we already have simple broadcast IPIs.
821
822 7.1 Initial Stuff
823 ---------------------------
824 One big issue is whether or not to wait for a response from the other vcores
825 that they have unmapped.  There are two concerns: 1) Page reuse and 2) User
826 semantics.  We cannot give out the physical page while it may still be in a
827 TLB (even to the same process.  Ask us about the pthread_test bug).
828
829 The second case is a little more detailed.  The application may not like it if
830 it thinks a page is unmapped or protected, and it does not generate a fault.
831 I am less concerned about this, especially since we know that even if we don't
832 wait to hear from every vcore, we know that the message was delivered and the
833 IPI sent.  Any cores that are in userspace will have trapped and eventually
834 handle the shootdown before having a chance to execute other user code.  The
835 delays in the shootdown response are due to being in the kernel with
836 interrupts disabled (it was an IMMEDIATE kmsg).
837
838 7.2 RCU
839 ---------------------------
840 One approach is similar to RCU.  Unmap the page, but don't put it on the free
841 list.  Instead, don't reallocate it until we are sure every core (possibly
842 just affected cores) had a chance to run its kmsg handlers.  This time is
843 similar to the RCU grace periods.  Once the period is over, we can then truly
844 free the page.
845
846 This would require some sort of RCU-like mechanism and probably a per-core
847 variable that has the timestamp of the last quiescent period.  Code caring
848 about when this page (or pages) can be freed would have to check on all of the
849 cores (probably in a bitmask for what needs to be freed).  It would make sense
850 to amortize this over several RCU-like operations.
851
852 7.3 Checklist
853 ---------------------------
854 It might not suck that much to wait for a response if you already sent an IPI,
855 though it incurs some more cache misses.  If you wanted to ensure all vcores
856 ran the shootdown handler, you'd have them all toggle their bit in a checklist
857 (unused for a while, check smp.c).  The only one who waits would be the
858 caller, but there still are a bunch of cache misses in the handlers.  Maybe
859 this isn't that big of a deal, and the RCU thing is an unnecessary
860 optimization.
861
862 7.4 Just Wait til a Context Switch
863 ---------------------------
864 Another option is to not bother freeing the page until the entire process is
865 descheduled.  This could be a very long time, and also will mess with
866 userspace's semantics.  They would be running user code that could still
867 access the old page, so in essence this is a lazy munmap/mprotect.  The
868 process basically has the page in pergatory: it can't be reallocated, and it
869 might be accessible, but can't be guaranteed to work.
870
871 The main benefit of this is that you don't need to send the TLB shootdown IPI
872 at all - so you don't interfere with the app.  Though in return, they have
873 possibly weird semantics.  One aspect of these weird semantics is that the
874 same virtual address could map to two different pages - that seems like a
875 disaster waiting to happen.  We could also block that range of the virtual
876 address space from being reallocated, but that gets even more tricky.
877
878 One issue with just waiting and RCU is memory pressure.  If we actually need
879 the page, we will need to enforce an unmapping, which sucks a little.
880
881 7.5 Bulk vs Single
882 ---------------------------
883 If there are a lot of pages being shot down, it'd be best to amortize the cost
884 of the kernel messages, as well as the invlpg calls (single page shootdowns).
885 One option would be for the kmsg to take a range, and not just a single
886 address.  This would help with bulk munmap/mprotects.  Based on the number of
887 these, perhaps a raw tlbflush (the entire TLB) would be worth while, instead
888 of n single shots.  Odds are, that number is arch and possibly workload
889 specific.
890
891 For now, the plan will be to send a range and have them individually shot
892 down.
893
894 7.6 Don't do it
895 ---------------------------
896 Either way, munmap/mprotect sucks in an MCP.  I recommend not doing it, and
897 doing the appropriate mmap/munmap/mprotects in _S mode.  Unfortunately, even
898 our crap pthread library munmaps on demand as threads are created and
899 destroyed.  The vcore code probably does in the bowels of glibc's TLS code
900 too, though at least that isn't on every user context switch.
901
902 7.7 Local memory
903 ---------------------------
904 Private local memory would help with this too.  If each vcore has its own
905 range, we won't need to send TLB shootdowns for those areas, and we won't have
906 to worry about weird application semantics.  The downside is we would need to
907 do these mmaps in certain ranges in advance, and might not easily be able to
908 do them remotely.  More on this when we actually design and build it.
909
910 7.8 Future Hardware Support
911 ---------------------------
912 It would be cool and interesting if we had the ability to remotely shootdown
913 TLBs.  For instance, all cores with cr3 == X, shootdown range Y..Z.  It's
914 basically what we'll do with the kernel message and the vcoremap, but with
915 magic hardware.
916
917 7.9 Current Status
918 ---------------------------
919 For now, we just send a kernel message to all vcores to do a full TLB flush,
920 and not to worry about checklists, waiting, or anything.  This is due to being
921 short on time and not wanting to sort out the issue with ranges.  The way
922 it'll get changed to is to send the kmsg with the range to the appropriate
923 cores, and then maybe put the page on the end of the freelist (instead of the
924 head).  More to come.
925
926 8. Process Management
927 ===========================
928 8.1 Vcore lists
929 ---------------------------
930 We have three lists to track a process's vcores.  The vcores themselves sit in
931 the vcoremap in procinfo; they aren't dynamically allocated (memory) or
932 anything like that.  The lists greatly eases vcore discovery and management.
933
934 A vcore is on exactly one of three lists: online (mapped and running vcores,
935 sometimes called 'active'), bulk_preempt (was online when the process was bulk
936 preempted (like a timeslice)), and inactive (yielded, hasn't come on yet,
937 etc).  When writes are complete (unlocked), either the online list or the
938 bulk_preempt list should be empty.
939
940 List modifications are protected by the proc_lock.  You can concurrently read,
941 but note you may get some weird behavior, such as a vcore on multiple lists, a
942 vcore on no lists, online and bulk_preempt both having items, etc.  Currently,
943 event code will read these lists when hunting for a suitable core, and will
944 have to be careful about races.  I want to avoid event FALLBACK code from
945 grabbing the proc_lock.
946
947 Another slight thing to be careful of is that the vcore lists don't always
948 agree with the vcore mapping.  However, it will always agree with what the
949 state of the process will be when all kmsgs are processed (fate).
950 Specifically, when we take vcores, the unmapping happens with the lock not
951 held on the vcore itself (as discussed elsewhere).  The vcore lists represent
952 the result of those pending unmaps.
953
954 Before we used the lists, we scanned the vcoremap in a painful, clunky manner.
955 In the old style, when you asked for a vcore, the first one you got was the
956 first hole in the vcoremap.  Ex: Vcore0 would always be granted if it was
957 offline.  That's no longer true; the most recent vcore yielded will be given
958 out next.  This will help with cache locality, and also cuts down on the
959 scenarios on which the kernel gives out a vcore that userspace wasn't
960 expecting.  This can still happen if they ask for more vcores than they set up
961 for, or if a vcore doesn't *want* to come online (there's a couple scenarios
962 with preemption recovery where that may come up).
963
964 So the plan with the bulk preempt list is that vcores on it were preempted,
965 and the kernel will attempt to restart all of them (and move them to the online
966 list).  Any leftovers will be moved to the inactive list, and have preemption
967 recovery messages sent out.  Any shortages (they want more vcores than were
968 bulk_preempted) will be taken from the yield list.  This all means that
969 whether or not a vcore needs to be preempt-recovered or if there is a message
970 out about its preemption doesn't really affect which list it is on.  You could
971 have a vcore on the inactive list that was bulk preempted (and not turned back
972 on), and then that vcore gets granted in the next round of vcore_requests().
973 The preemption recovery handlers will need to deal with concurrent handlers
974 and the vcore itself starting back up.
975
976 9. TBD
977 ===========================