Rename EVENT_FALLBACK -> EVENT_SPAM_INDIR (XCC)
[akaros.git] / Documentation / async_events.txt
1 async_events.txt
2 Barret Rhoden
3
4 1. Overview
5 2. Async Syscalls and I/O
6 3. Event Delivery / Notification
7 4. Single-core Process (SCP) Events
8 5. Misc Things That Aren't Sorted Completely:
9
10 1. Overview
11 ====================
12 1.1 Event Handling / Notifications / Async IO Issues:
13 ------------------------------------------------------------------
14 Basically, syscalls use the ROS event delivery mechanisms, redefined and
15 described below.  Syscalls use the event delivery just like any other
16 subsystem would that wants to deliver messages to a process.  The only other
17 example we have right now are the "kernel notifications", which are the
18 one-sided, kernel-initiated messages that the kernel sends to a process.
19
20 Overall, there are several analogies from how vcores work to how the OS
21 handles interrupts.  This is a result of trying to make vcores run like
22 virtual multiprocessors, in control of their resources and aware of the lower
23 levels of the system.  This analogy has guided much of how the vcore layer
24 works.  Whenever we have issues with the 2-lsched, realize the amount of
25 control they want means using solutions that the OS must do too.
26
27 Note that there is some pointer chasing going on, though we try to keep it to
28 a minimum.  Any time the kernel chases a pointer, it needs to make sure it is
29 in the R/W section of userspace, though it doesn't need to check if the page
30 is present.  There's more info in the Page Fault sections of the
31 documentation.  (Briefly, if the kernel PFs on a user address, it will either
32 block and handle the PF, or if the address was unmapped, it will kill the
33 process).
34
35 1.2 Some Definitions:
36 ---------------------------------------
37 ev_q, event_queue, event_q: all terms used interchangeably with each other.
38 They are the endpoint for communicating messages to a process, encapsulating
39 the method of delivery (such as IPI or not) with where to save the message.
40
41 Vcore context: the execution context of the virtual core on the "trampoline"
42 stack.  All executions start from the top of this stack, and no stack state is
43 saved between vcore_entry() calls.  All executions on here are non-blocking,
44 notifications (IPIs) are disabled, and there is a specific TLS loaded.  Vcore
45 context is used for running the second level scheduler (2LS), swapping between
46 threads, and handling notifications.  It is analagous to "interrupt context"
47 in the OS.  Any functions called from here should be brief.  Any memory
48 touched must be pinned.  In Lithe terms, vcore context might be called the
49 Hart / hard thread.  People often wonder if they can run out of vcore context
50 directly.  Technically, you can, but you lose the ability to take any fault
51 (page fault) or to get IPIs for notification.  In essence, you lose control,
52 analgous to running an application in the kernel with preemption/interrupts
53 disabled.  See the process documentation for more info.
54
55 2LS: is the second level scheduler/framework.  This code executes in vcore
56 context, and is Lithe / plugs in to Lithe (eventually).  Often used
57 interchangeably with "vcore context", usually when I want to emphasize the
58 scheduling nature of the code.
59
60 VCPD: "virtual core preemption data".  In procdata, there is an array of
61 struct preempt_data, one per vcore.  This is the default location to look for
62 all things related to the management of vcores, such as its event_mbox (queue
63 of incoming messages/notifications/events).  Both the kernel and the vcore
64 code know to look here for a variety of things.
65
66 Vcore-business: This is a term I use for a class of messages where the receiver
67 is the actual vcore, and not just using the vcore as a place to receive the
68 message.  Examples of vcore-business are INDIR events, preempt_pending events,
69 scheduling events (self-ipis by the 2LS from one vcore to another), and things
70 like that.  There are two types: public and private.  Private will only be
71 handled by that vcore.  Public might be handled by another vcore.
72
73 Notif_table: This is a list of event_q*s that correspond to certain
74 unexpected/"one-sided" events the kernel sends to the process.  It is similar
75 to an IRQ table in the kernel.  Each event_q tells the kernel how the process
76 wants to be told about the specific event type.
77
78 Notifications: used to be a generic event, but now used in terms of the verb
79 'notify' (do_notify()).  In older docs, passive notification is just writing a
80 message somewhere.  Active notification is an IPI delivered to a vcore.  I use
81 that term interchangeably with an IPI, and usually you can tell by context
82 that I'm talking about an IPI going to a process (and not just the kernel).
83 The details of it make it more complicated than just an IPI, but it's
84 analagous.  I've start referring to notification as the IPI, and "passive
85 notification" as just events, though older documentation has both meanings.
86
87 BCQ: "bounded concurrent queue".  It is a fixed size array of messages
88 (structs of notification events, or whatever).  It is non-blocking, supporting
89 multiple producers and consumers, where the producers do not trust the
90 consumers.  It is the primary mechanism for the kernel delivering message
91 payloads into a process's address space.  Note that producers don't trust each
92 other either (in the event of weirdness, the producers give up and say the
93 buffer is full).  This means that a process can produce for one of its ev_qs
94 (which is what they need to do to send message to itself).
95
96 UCQ: "unbounded concurrent queue".  This is a data structure allowing the kernel
97 to produce an unbounded number of messages for the process to consume.  The main
98 limitation to the number of messages is RAM.  Check out its documentation.
99
100 2. Async Syscalls and I/O
101 ====================
102 2.1 Basics
103 ----------------------------------------------
104 The syscall struct is the contract for work with the kernel, including async
105 I/O.  Lots of current OS async packages use epoll or other polling systems.
106 Note the distinction between Polling and Async I/O.  Polling is about finding
107 out if a call will block.  It is primarily used for sockets and pipes.  It
108 does relatively nothing for disk I/O, which requires a separate async I/O
109 system.  By having all syscalls be async, we can make polling a bit easier and
110 more unified with the generic event code that we use for all syscalls.
111
112 For instance, we can have a sys_poll syscall, which is async just like any
113 other syscall.  The call can be a "one shot / non-blocking", like the current
114 systems polling code, or it can also notify on change (not requiring future
115 polls) via the event_q mechanisms.  If you don't want to be IPId, you can
116 "poll" the syscall struct - not requiring another kernel crossing/syscall.
117
118 Note that we do not tie syscalls and polling to FDs.  We do events on
119 syscalls, which can be used to check FDs.  I think a bunch of polling cases
120 will not be needed once we have async syscalls, but for those that remain,
121 we'll have sys_poll() (or whatever).
122
123 To receive an event on a syscall completion or status change, just fill in the
124 event_q pointer.  If it is 0, the kernel will assume you poll the actual
125 syscall struct.
126
127         struct syscall {
128                 current stuff                   /* arguments, retvals */
129                 struct ev_queue *               /* struct used for messaging, including IPIs*/
130                 void *                                  /* used by 2LS, usually a struct u_thread * */
131         }
132
133 One issue with async syscalls is that there can be too many outstanding IOs
134 (normally sync calls provide feedback / don't allow you to over-request).
135 Eventually, processes can exhaust kernel memory (the kthreads, specifically).
136 We need a way to limit the kthreads per proc, etc.  Shouldn't be a big deal.
137
138 Normally, we talk about changing the flag in a syscall to SC_DONE.  Async
139 syscalls can be SC_PROGRESS (new stuff happened on it), which can trigger a
140 notification event.  Some calls, like AIO or bulk accept, exist for a while
141 and slowly get filled in / completed.  In the future, we'll also want a way to
142 abort the in-progress syscalls (possibly any syscall!).
143
144 2.2 Uthreads Blocking on Syscalls
145 ----------------------------------------------
146 Many threading libraries will want some notion of a synchronous, blocking
147 thread.  These threads use regular I/O calls, which are async under the hood,
148 but don't want to bother with call backs or other details of async I/O.  In
149 this section, I'll talk a bit about how this works, esp regarding
150 uthreads/pthreads.
151
152 'Blocking' refers to user threads, and has nothing to do with an actual
153 process blocking/waiting on some kernel event.  The kernel does not know
154 anything about what goes on here.  While a bit confusing, this allows
155 applications to do whatever they want on top of an async interface, and is a
156 consequence of decoupling cores from user-threads from kthreads.
157
158 2.2.1 Basics of Uthread Blocking
159 ---------------
160 When a thread calls a glibc function that makes a system call, if the syscall
161 is not yet complete when the kernel returns to userspace, glibc will check for
162 the existence of a second level scheduler and attempt to use it to yield its
163 uthread.  If there is no 2LS, the code just spins for now.  Eventually, it
164 will try to suspend/yield the process for a while (til the call is done), aka,
165 block in the kernel.
166
167 If there is a 2LS, the current thread will yield, and call out to the 2LS's
168 blockon_sysc() method, which needs a way to stop the thread and be able to
169 restart it when the syscall completes.  Specifically, the pthread 2LS registers
170 the syscall to respond to an event (described in detail elsewhere in this doc).
171 When the event comes in, meaning the syscall is complete, the thread is put on
172 the runnable list.
173
174 Details:
175 - A pointer to the struct pthread is stored in the syscall's void*.  When the
176   syscall is done, we normally get a message from the kernel, and the payload
177   tells us the syscall is done, which tells us which thread to unblock. 
178 - The pthread code also always asks for an IPI and event message for every
179   syscall that completes.  This is far from ideal.  Still, the basics are the
180   same for any threading library.  Once you know a thread is done, you need to
181   do something about it.
182 - The pthread code does syscall blocking and event notification on a per-core
183   basis.  Using the default (VCPD) ev_mbox for this is a bad idea (which we did
184   at some point).
185 - There's a race between the 2LS trying to sign up for events and the kernel
186   finishing the event.  We handle this in uthread code, so use the helper to
187   register_evq(), which does the the right thing (atomics, careful ordering
188   with writes, etc).
189
190 2.2.1 Recovering from Event Overflow
191 ---------------
192 Event overflow recovery is unnecessary, since syscall ev_qs use UCQs now.  this
193 section is kept around for some useful tidbits, such as details about
194 deregistering ev_qs for a syscall:
195
196 ---------------------------
197 The pthread code expects to receive an event somehow to unblock a thread
198 once its syscall is done.  One limitation to our messaging systems is that you
199 can't send an infinite amount of event messages.  (By messages, I mean a chunk
200 of memory with a payload, in this case consisting of a struct syscall *).
201 Event delivery degrades to a bit in the case of the message queue being full
202 (more details on that later).
203
204 The pthread code (and any similar 2LS) needs to handle waking up syscalls when
205 the event message was lost and all we know is that some syscall that was meant
206 to have a message sent to a particular event queue (per-core in the case of
207 pthread stuff (actually the VCPD for now)).  The basic idea is to poll all
208 outstanding system calls and unblock whoever is done.
209
210 The key problem is due to a race: for a given syscall we don't know if we're
211 going to get a message for a syscall or not.  There could be a completion
212 message in the queue for the syscall while we are going through the list of
213 blocked threads.  If we assume we already got the message (or it was lost in
214 the overflow), but didn't really, then if we finish as SC and free its memory
215 (free or return up the stack), we could later get a message for it, and all
216 sorts of things would go wrong (like trying to unblock a pointer that is
217 gibberish).
218
219 Here's what we do:
220 1) Set a "handling overflow" flag so we don't recurse.
221 2) Turn off event delivery for all syscalls on our list
222 3) Handle any event messages.  This is how we make a distinction between
223 finished syscalls that had a message sent and those that didn't.  We're doing
224 the message-sent ones here.
225 4) For any left on the list, check to see if they are done.  We actually do
226 this by attempting to turn on event delivery for them.  Turning on event
227 delivery can fail if the call is already done.  So if it fails, they are done
228 and we unblock them (similar to how we block the threads in the first place).
229 If it doesn't fail, they are now ready to receive messages.  This can be
230 tweaked a bit.
231 5) Unset the overflow-handling flag.
232
233 One thing to be careful of is that when we turn off event delivery, you need to
234 be sure the kernel isn't in the process of sending an event.  This is why we
235 have the SC_K_LOCK syscall flag.  Uthread code will not consider deregistration
236 complete while that flag is set, since the kernel is still mucking with the
237 syscall (and sending an event).  Once the flag is clear, the event has been
238 delivered (the ev_msg is in the ev_mbox), and our assumptions remain true.
239
240 There are a couple implications of this style.  If you have a shared event
241 queue (with other event sources), those events can get mixed in with the
242 recovery.  Don't leave the vcore context due to other events.  This'll
243 probably need work.  The other thing is that completed syscalls can get
244 handled in a different order than they were signaled.  Shouldn't be a big
245 deal.
246
247 Note on the overflow handling flag and unsetting it.  There should not be any
248 races with this.  The flag prevented us from handling overflows on the event
249 queue.  Other than when we checked for events that had been succesfully sent,
250 we didn't try to handle events.  We can unset the flag, and at that point we
251 can start handling missed events.  If there was an overflow after we last
252 checked the list, but before we cleared the overflow-handling flag, we'll
253 still catch it since we haven't tried handling events in between checking the
254 list and clearing the flag.  That flag doesn't even matter until we want to
255 handle_events, so we aren't missing anything.  the next handle_events() will
256 deal with everything from scratch.
257
258 For blocking threads that block concurrently with the overflow handling: in
259 the pthread case, this can't happen since everything is per-vcore.  If you do
260 have process-wide thread blocking/syscall management, we can add new ones, but
261 they must have event delivery turned off when they are added to the list.  And
262 you'll need to lock the list, etc.  This should work in part due to new
263 syscalls being added to the end of the list, and the overflow-handler
264 proceeding linearly through the list.
265
266 Also note that we shouldn't handle the event for unblocking a syscall on a
267 different core than the one it was submitted to.  This could result in
268 concurrent modifications to the original core's TAILQ (bad).  This restriction
269 is dependent on how a 2LS does its thread handling/blocking.
270
271 Eventually, we'll want a way to detect and handle excessive overflow, since
272 it's probably quite expensive.  Perhaps turn it off and periodically poll the
273 syscalls for completion (but don't bother turning on the ev_q).
274 ---------------------------
275
276 3. Event Delivery / Notification
277 ====================
278 3.1 Basics
279 ----------------------------------------------
280 The mbox (mailbox) is where the actual messages go.
281
282         struct ev_mbox {
283                 bcq of notif_events     /* bounded buffer, multi-consumer/producer */
284                 msg_bitmap
285         }
286         struct ev_queue {                       /* aka, event_q, ev_q, etc. */
287                 struct ev_mbox * 
288                 void handler(struct event_q *)
289                 vcore_to_be_told
290                 flags                                   /* IPI_WANTED, RR, 2L-handle-it, etc */
291         }
292         struct ev_queue_big {
293                 struct ev_mbox *                /* pointing to the internal storage */
294                 vcore_to_be_told
295                 flags                                   /* IPI_WANTED, RR, 2L-handle-it, etc */
296                 struct ev_mbox { }              /* never access this directly */
297         }
298
299 The purpose of the big one is to simply embed some storage.  Still, only
300 access the mbox via the pointer.  The big one can be casted (and stored as)
301 the regular, so long as you know to dealloc a big one (free() knows, custom
302 styles or slabs would need some help).
303
304 The ev_mbox says where to put the actual message, and the flags handle things
305 such as whether or not an IPI is wanted.
306
307 Using pointers for the ev_q like this allows multiple event queues to use the
308 same mbox.  For example, we could use the vcpd queue for both kernel-generated
309 events as well as async syscall responses.  The notification table is actually
310 a bunch of ev_qs, many of which could be pointing to the same vcore/vcpd-mbox,
311 albeit with different flags.
312
313 3.2 Kernel Notification Using Event Queues
314 ----------------------------------------------
315 The notif_tbl/notif_methods (kernel-generated 'one-sided' events) is just an
316 array of struct ev_queue*s.  Handling a notification is like any other time
317 when we want to send an event.  Follow a pointer, send a message, etc.  As
318 with all ev_qs, ev_mbox* points to where you want the message for the event,
319 which usually is the vcpd's mbox.  If the ev_q pointer is 0, then we know the
320 process doesn't want the event (equivalent to the older 'NOTIF_WANTED' flag).
321 Theoretically, we can send kernel notifs to user threads.  While it isn't
322 clear that anyone will ever want this, it is possible (barring other issues),
323 since they are just events.
324
325 Also note the flag EVENT_VCORE_APPRO.  Processes should set this for certain
326 types of events where they want the kernel to send the event/IPI to the
327 'appropriate' vcore.  For example, when sending a message about a preemption
328 coming in, it makes sense for the kernel to send it to the vcore that is going
329 to get preempted, but the application could choose to ignore the notification.
330 When this flag is set, the kernel will also use the vcore's ev_mbox, ignoring
331 the process's choice.  We can change this later, but it doesn't really make
332 sense for a process to pick an mbox and also say VCORE_APPRO.
333
334 There are also interfaces in the kernel to put a message in an ev_mbox
335 regardless of the process's wishes (post_vcore_event()), and can send an IPI
336 at any time (proc_notify()).
337
338 3.3 IPIs, Indirection Events, and Fallback (Spamming Indirs)
339 ----------------------------------------------
340 An ev_q can ask for an IPI, for an indirection event, and for an indirection
341 event to be spammed in case a vcore is offline (sometimes called the 'fallback'
342 option.  Or any combination of these.  Note that these have little to do with
343 the actual message being sent.  The actual message is dropped in the ev_mbox
344 pointed to by the ev_q.
345
346 The main use for all of this is for syscalls.  If you want to receive an event
347 when a syscall completes or has a change in status, simply allocate an event_q,
348 and point the syscall at it.  syscall: ev_q* -> "vcore for IPI, syscall message
349 in the ev_q mbox", etc.  You can also point it to an existing ev_q.  Pthread
350 code has examples of two ways to do this.  Both have per vcore ev_qs, requesting
351 IPIs, INDIRS, and SPAM_INDIR.  One way is to have an ev_mbox per vcore, and
352 another is to have a global ev_mbox that all ev_qs point to.  As a side note, if
353 you do the latter, you don't need to worry about a vcore's ev_q if it gets
354 preempted: just check the global ev_mbox (which is done by checking your own
355 vcore's syscall ev_q).
356
357 3.3.1: IPIs and INDIRs
358 ---------------
359 An EVENT_IPI simply means we'll send an IPI to the given vcore.  Nothing else.
360 This will usually be paired with an Indirection event (EVENT_INDIR).  An INDIR
361 is a message of type EV_EVENT with an ev_q* payload.  It means "check this
362 ev_q".  Most ev_qs that ask for an IPI will also want an INDIR so that the vcore
363 knows why it was IPIed.  You don't have to do this: for instance, your 2LS might
364 poll its own ev_q, so you won't need the indirection event.
365
366 Additionally, note that IPIs and INDIRs can be spurious.  It's not a big deal to
367 receive and IPI and have nothing to do, or to be told to check an empty ev_q.
368 All of the event handling code can deal with this.
369
370 INDIR events are sent to the VCPD public mbox, which means they will get handled
371 if the vcore gets preempted.  Any other messages sent here will also get handled
372 during a preemption.  However, the only type of messages you should use this for
373 are ones that can handle spurious messages.  The completion of a syscall is an
374 example of a message that cannot be spurious.  Since INDIRs can be spurious, we
375 can use the public mbox.  (Side note: the kernel may spam INDIRs in attempting
376 to make sure you get the message on a vcore that didn't yield.)
377
378 Never use a VCPD mbox (public or private) for messages you might want to receive
379 if that vcore is offline.  If you want to be sure to get a message, create your
380 own ev_q and set flags for INDIR, SPAM_INDIR, and IPI.  There's no guarantee a
381 *specific* message will get looked at.  In cases where it won't, the kernel will
382 send that message to another vcore.  For example, if the kernel posts an INDIR
383 to a VCPD mbox (the public one btw) and it loses a race with the vcore yielding,
384 the vcore might never see that message.  However, the kernel knows it lost the
385 race, and will find another vcore to send it to.
386
387 3.3.2: Spamming Indirs / Fallback
388 ---------------
389 Both IPI and INDIR need an actual vcore.  If that vcore is unavailable and if
390 EVENT_SPAM_INDIR is set, the kernel will pick another vcore and send the
391 messages there.  This allows an ev_q to be set up to handle work when the vcore
392 is online, while allowing the program to handle events when that core yields,
393 without having to reset all of its ev_qs to point to "known" available vcores
394 (and avoiding those races).  Note 'online' is synonymous with 'mapped', when
395 talking about vcores.  A vcore technically isn't always online, only destined
396 to be online, when it is mapped to a pcore (kmsg on the way, etc).  It's
397 easiest to think of it being online for the sake of this discussion.
398
399 One question is whether or not 2LSs need a SPAM_INDIR flag for their ev_qs.
400 The main use for SPAM_INDIR is so that vcores can yield.  (Note that fallback
401 won't help you *miss* INDIR messages in the event of a preemption; you can
402 always lose that race due to it taking too long to process the messages).  An
403 alternative would be for vcores to pick another vcore and change all of its
404 ev_qs to that vcore.  There are a couple problems with this.  One is that it'll
405 be a pain to get those ev_qs back when the vcore comes back online (if ever).
406 Another issue is that other vcores will build up a list of ev_qs that they
407 aren't aware of, which will be hard to deal with when *they* yield.  SPAM_INDIR
408 avoids all of those problems.
409
410 An important aspect of spamming indirs is that it works with yielded vcores,
411 not preempted vcores.  It could be that there are no cores that are online, but
412 there should always be at least one core that *will* be online in the future, a
413 core that the process didn't want to lose and will deal with in the future.  If
414 not for this distinction, SPAM_INDIR could fail.  An older idea would be to have
415 fallback send the msg to the desired vcore if there were no others.  This would
416 not work if the vcore yielded and then the entire process was preempted or
417 otherwise not running.  Another way to put this is that we need a field to
418 determine whether a vcore is offline temporarily or permanently.
419
420 This is why we have the VCPD flag 'VC_CAN_RCV_MSG'.  It tells the kernel's event
421 delivery code that the vcore will check the messages: it is an acceptable
422 destination for a spammed indir.  There are two reasons to put this in VCPD:
423 1) Userspace can remotely turn off a vcore's msg reception.  This is necessary
424 for handling preemption of a vcore that was in uthread context, so that we can
425 remotely 'yield' the core without having to sys_change_vcore() (which I discuss
426 below, and is meant to 'unstick' a vcore).
427 2) Yield is simplified.  The kernel no longer races with itself nor has to worry
428 about turning off that flag - userspace can do it when it wants to yield.  (turn
429 off the flag, check messages, then yield).  This is less big of a deal now that
430 the kernel races with vcore membership in the online_vcs list.
431
432 Two aspects of the code make this work nicely.  The VC_CAN_RCV_MSG flag greatly
433 simplifies the kernel's job.  There are a lot of weird races we'd have to deal
434 with, such as process state (RUNNING_M), whether a mass preempt is going on, or
435 just one core, or a bunch of cores, mass yields, etc.  A flag that does one
436 thing well helps a lot - esp since preemption is not the same as yielding.  The
437 other useful thing is being able to handle spurious events.  Vcore code can
438 handle extra IPIs and INDIRs to non-VCPD ev_qs.  Any vcore can handle an ev_q
439 that is "non-VCPD business".
440
441 Worth mentioning is the difference between 'notif_pending' and VC_CAN_RCV_MSG.
442 VC_CAN_RCV_MSG is the process saying it will check for messages.
443 'notif_pending' is when the kernel says it *has* sent a message.
444 'notif_pending' is also used by the kernel in proc_yield() and the 2LS in
445 pop_user_ctx() to make sure the sent message is not missed.
446
447 Also, in case this comes up, there's a slight race on changing the mbox* and the
448 vcore number within the event_q.  The message could have gone to the wrong (old)
449 vcore, but not the IPI.  Not a big deal - IPIs can be spurious, and the other
450 vcore will eventually get it.  The real way around this is create a new ev_q and
451 change the pointer (thus atomically changing the entire ev_q's contents), though
452 this can be a bit tricky if you have multiple places pointing to the same ev_q
453 (can't change them all at once).
454
455 3.3.3: Fallback and Preemption
456 ---------------
457 SPAM_INDIR doesn't protect you from preemptions.  A vcore can be preempted and
458 have INDIRs in its VCPD.
459
460 It is tempting to just use sys_change_vcore(), which will change the calling
461 vcore to the new one.  This should only be used to "unstick" a vcore.  A vcore
462 is stuck when it was preempted while it had notifications disabled.  This is
463 usually when it is vcore context, but also in any lock holding code for locks
464 shared with vcore context (the userspace equivalent of irqsave locks).  With
465 this syscall, you could change to the offline vcore and process its INDIRs.
466
467 The problem with that plan is the calling core (that is trying to save the
468 other) may have extra messages, and that sys_change_vcore does not return.  We
469 need a way to deal with our other messages.  We're back to the same problem we
470 had before, just with different vcores.  The only thing we really accomplished
471 is that we unstuck the other vcore.  We could tell the restarted vcore (via an
472 event) to switch back to us, but by the time it does that, it may have other
473 events that got lost.  So we're back to polling the ev_qs that it might have
474 received INDIRs about.  Note that we still want to send an event with
475 sys_change_vcore().  We want the new vcore to know the old vcore was put
476 offline: a preemption (albeit one that it chose to do, and one that isn't stuck
477 in vcore context).
478
479 One older way to deal with this was to force the 2LS to deal with this. The 2LS
480 would check the ev_mboxes/ev_qs of all ev_qs that could send INDIRS to the
481 offline vcore.  There could be INDIRS in the VCPD that are just lying there.
482 The 2LS knows which ev_qs these are (such as for completed syscalls), and for
483 many things, this will be a common ev_q (such as for 'vcore-x-was-preempted').
484 However, this is a huge pain in the ass, since a preempted vcore could have the
485 spammed INDIR for an ev_q associated with another vcore.  To deal with this,
486 the 2LS would need to check *every* ev_q that requests INDIRs.  We don't do
487 this.
488
489 Instead, we simply have the remote core check the VCPD public mbox of the
490 preempted vcore.  INDIRs (and other vcore business that other vcores can handle)
491 will get sorted here.
492
493 3.3.5: Lists to Find Vcores
494 ---------------
495 A process has three lists: online, bulk_preempt, and inactive.  These not only
496 are good for process management, but also for helping alert_vcore() find
497 potentially alertable vcores.  alert_vcore() and its associated helpers are
498 failry complicated and heavily commented.  I've set things up so both the
499 online_vcs and the bulk_preempted_vcs lists can be handled the same way: post to
500 the first element, then see if it still VC_CAN_RCV_MSG.  If not, if it is still
501 the first on the list, then it hasn't proc_yield()ed yet, and it will eventually
502 restart when it tries to yield.  And this all works without locking the
503 proc_lock.  There are a bunch more details and races avoided.  Check the code
504 out.
505
506 3.3.6: Vcore Business and the VCPD mboxs
507 ---------------
508 There are two types of VCPD mboxes: public and private.  Public ones will get
509 handled during preemption recovery.  Messages sent here need to be handle-able
510 by any vcore.  Private messages are for that specific vcore.  In the common
511 case, the public mbox will usually only get looked at by its vcore.  Only during
512 recovery and some corner cases will we deal with it remotely.
513
514 Here's some guidelines: if you message is spammy and the handler can deal with
515 spurious events and it doesn't need to be on a specific vcore, then go with
516 public.  Examples of public mbox events are ones that need to be spammed:
517 preemption recovery, INDIRs, etc.  Note that you won't need to worry about
518 these: uthread code and the kernel handle them.  But if you have something
519 similar, then that's where it would go.  You can also send non-spammy things,
520 but there's no guarantee they'll be looked at.
521
522 Some messages should only be sent to the private mbox.  These include ones that
523 make no sense for other vcores to handle.  Examples: 2LS IPIs/preemptions (like
524 "change your scheduling policy vcore 3", preemption-pending notifs from the
525 kernel, timer interrupts, etc.
526
527 An example of something that shouldn't be sent to either is syscall completions.
528 They can't be spammed, so you can't send them around like INDIRs.  And they need
529 to be dealt with.  Other than carefully-spammed public messages, there's no
530 guarantee of getting a message for certain scenarios (yields).  Instead, use an
531 ev_q with INDIR set.
532
533 Also note that a 2LS could set up a big ev_q with EVENT_IPI and not EVENT_INDIR,
534 and then poll for that in their vcore_entry().  This is equivalent to setting up
535 a small ev_q with EVENT_IPI and pointing it at the private mbox.
536
537 3.4 Application-specific Event Handling
538 ---------------------------------------
539 So what happens when the vcore/2LS isn't handling an event queue, but has been
540 "told" about it?  This "telling" is in the form of an IPI.  The vcore was
541 prodded, but is not supposed to handle the event.  This is actually what
542 happens now in Linux when you send signals for AIO.  It's all about who (which
543 thread, in their world) is being interrupted to process the work in an
544 application specific way.  The app sets the handler, with the option to have a
545 thread spawned (instead of a sighandler), etc.
546
547 This is not exactly the same as the case above where the ev_mbox* pointed to
548 the vcore's default mbox.  That issue was just about avoiding extra messages
549 (and messages in weird orders).  A vcore won't handle an ev_q if the
550 message/contents of the queue aren't meant for the vcore/2LS.  For example, a
551 thread can want to run its own handler, perhaps because it performs its own
552 asynchronous I/O (compared to relying on the 2LS to schedule synchronous
553 blocking u_threads).
554
555 There are a couple ways to handle this.  Ultimately, the application is supposed
556 to handle the event.  If it asked for an IPI, it is because something ought to
557 be done, which really means running a handler.  If the application sets
558 EVENT_THREAD in the ev_q's flags, the 2LS ought to spawn a thread to run the
559 ev_q's handler.  If EVENT_JUSTHANDLEIT is set, the vcore will execute the
560 handler itself.  Careful with this, since the only memory it touches must be
561 pinned, the function must not block (this is only true for the handlers called
562 directly out of vcore context), and it should return quickly.
563
564 Note that in either case, vcore-written code (library code) does not look at
565 the contents of the notification event.  Also note the handler takes the whole
566 event_queue, and not a specific message.  It is more flexible, can handle
567 multiple specific events, and doesn't require the vcore code to dequeue the
568 event and either pass by value or allocate more memory.
569
570 These ev_q handlers are different than ev_handlers.  The former handles an
571 event_queue.  The latter is the 2LS's way to handle specific types of messages.
572 If an app wants to process specific messages, have them sent to an ev_q under
573 its control; don't mess with ev_handlers unless you're the 2LS (or example
574 code).
575
576 Continuing the analogy between vcores getting IPIs and the OS getting HW
577 interrupts, what goes on in vcore context is like what goes on in interrupt
578 context, and the threaded handler is like running a threaded interrupt handler
579 (in Linux).  In the ROS world, it is like having the interrupt handler kick
580 off a kernel message to defer the work out of interrupt context.
581
582 If neither of the application-specific handling flags are set, the vcore will
583 respond to the IPI by attempting to handle the event on its own (lookup table
584 based on the type of event (like "syscall complete")).  If you didn't want the
585 vcore to handle it, then you shouldn't have asked for an IPI.  Those flags are
586 the means by which the vcore can distinguish between its event_qs and the
587 applications.  It does not make sense otherwise to send the vcore an IPI and
588 an event_q, but not tell give the code the info it needs to handle it.
589
590 In the future, we might have the ability to block a u_thread on an event_q, so
591 we'll have other EV_ flags to express this, and probably a void*.  This may
592 end up being redudant, since u_threads will be able to block on syscalls (and
593 not necessarily IPIs sent to vcores).
594
595 As a side note, a vcore can turn off the IPI wanted flag at any time.  For
596 instance, when it spawns a thread to handle an ev_q, the vcore can turn off
597 IPI wanted on that event_q, and the thread handler can turn it back on when it
598 is done processing and wants to be re-IPId.  The reason for this is to avoid
599 taking future IPIs (once we leave vcore context, IPIs are enabled) to let us
600 know about an event for which a handler is already running.
601
602 3.5 Overflowed/Missed Messages in the VCPD 
603 ---------------------------------------
604 This too is no longer necessary.  It's useful in that it shows what we don't
605 have to put up with.  Missing messages requires potentially painful
606 infrastructure to handle it:
607
608 -----------------------------
609 All event_q's requesting IPIs ought to register with the 2LS.  This is for
610 recovering in case the vcpd's mbox overflowed, and the vcore knows it missed a
611 NE_EVENT type message.  At that point, it would have to check all of its
612 IPI-based queues.  To do so, it could check to see if the mbox has any
613 messages, though in all likelihood, we'll just act as if there was a message
614 on each of the queues (all such handlers should be able to handle spurious
615 IPIs anyways).  This is analagous to how the OS's block drivers don't solely
616 rely on receiving an interrupt (they deal with it via timeouts).  Any user
617 code requiring an IPI must do this.  Any code that runs better due to getting
618 the IPI ought to do this.
619
620 We could imagine having a thread spawned to handle an ev_q, and the vcore
621 never has to touch the ev_q (which might make it easier for memory
622 allocation).  This isn't a great idea, but I'll still explain it.  In the
623 notif_ev message sent to the vcore, it has the event_q*.  We could also send a
624 flag with the same info as in the event_q's flags, and also send the handler.
625 The problem with this is that it isn't resilient to failure.  If there was a
626 message overflow, it would have the check the event_q (which was registered
627 before) anyway, and could potentially page fault there.  Also the kernel would
628 have faulted on it (and read it in) back when it tried to read those values.
629 It's somewhat moot, since we're going to have an allocator that pins event_qs.
630 -----------------------------
631
632 3.6 Round-Robin or Other IPI-delivery styles
633 ---------------------------------------
634 In the same way that the IOAPIC can deliver interrupts to a group of cores,
635 round-robinning between them, so can we imagine processes wanting to
636 distribute the IPI/active notification of events across its vcores.  This is
637 only meaningful is the NOTIF_IPI_WANTED flag is set.
638
639 Eventually we'll support this, via a flag in the event_q.  When
640 NE_ROUND_ROBIN, or whatever, is set a couple things will happen.  First, the
641 vcore field will be used in a "delivery-specific" manner.  In the case of RR,
642 it will probably be the most recent destination.  Perhaps it will be a bitmask
643 of vcores available to receive.  More important is the event_mbox*.  If it is
644 set, then the event message will be sent there.  Whichever vcore gets selected
645 will receive an IPI, and its vcpd mbox will get a NE_EVENT message.  If the
646 event_mbox* is 0, then the actual message will get delivered to the vcore's
647 vcpd mbox (the default location).
648
649 3.7 Event_q-less Notifications
650 ---------------------------------------
651 Some events needs to be delivered directly to the vcore, regardless of any
652 event_qs.  This happens currently when we bypass the notification table (e.g.,
653 sys_self_notify(), preemptions, etc).  These notifs will just use the vcore's
654 default mbox.  In essence, the ev_q is being generated/sent with the call.
655 The implied/fake ev_q points to the vcpd's mbox, with the given vcore set, and
656 with IPI_WANTED set.  It is tempting to make those functions take a
657 dynamically generated ev_q, though more likely we'll just use the lower level
658 functions in the kernel, much like the Round Robin set will need to do.  No
659 need to force things to fit just for the sake of using a 'solution'.  We want
660 tools to make solutions, not packaged solutions.
661
662 3.8 UTHREAD_DONT_MIGRATE
663 ---------------------------------------
664 DONT_MIGRATE exists to allow uthreads to disable notifications/IPIs and enter
665 vcore context.  It is needed since you need to read vcoreid to disable notifs,
666 but once you read it, you need to not move to another vcore.  Here are a few
667 rules/guidelines.
668
669 We turn off the flag so that we can disable notifs, but turn the flag back on
670 before enabling.  The thread won't get migrated in that instant since notifs are
671 off.  But if it was the other way, we could miss a message (because we skipped
672 an opportunity to be dropped into vcore context to read a message).
673
674 Don't check messages/handle events when you have a DONT_MIGRATE uthread.  There
675 are issues with preemption recovery if you do.  In short, if two uthreads are
676 both DONT_MIGRATE with notifs enabled on two different vcores, and one vcore
677 gets preempted while the other gets an IPI telling it to recover the other one,
678 both could keep bouncing back and forth if they handle their preemption
679 *messages* without dealing with their own DONT_MIGRATEs first.  Note that the
680 preemption recovery code can handle having a DONT_MIGRATE thread on the vcore.
681 This is a special case, and it is very careful about how cur_uthread works.
682
683 All uses of DONT_MIGRATE must reenable notifs (and check messages) at some
684 point.  One such case is uthread_yield().  Another is mcs_unlock_notifsafe().
685 Note that mcs_notif_safe locks have uthreads that can't migrate for a
686 potentially long time.  notifs are also disabled, so it's not a big deal.  It's
687 basically just the same as if you were in vcore context (though technically you
688 aren't) when it comes to preemption recovery: we'll just need to restart the
689 vcore via a syscall.  Also note that it would be a real pain in the ass to
690 migrate a notif_safe locking uthread.  The whole point of it is in case it grabs
691 a lock that would be held by vcore context, and there's no way to know it isn't
692 a lock on the restart-path.
693
694 3.9 Why Preemption Handling Doesn't Lock Up (probably)
695 ---------------------------------------
696 One of the concerns of preemption handling is that we don't get into some form
697 of livelock, where we ping-pong back and forth between vcores (or a set of
698 vcores), all of which are trying to handle each other's preemptions.  Part of
699 the concern is that when a vcore sys_changes to another, it can result in
700 another preemption message being sent.  We want to be sure that we're making
701 progress, and not just livelocked doing sys_change_vcore()s.
702
703 A few notes first:
704 1) If a vcore is holding locks or otherwise isn't handling events and is
705 preempted, it will let go of its locks before it gets to the point of
706 attempting to handle any other vcore preemption events.  Event handling is only
707 done when it is okay to never return (meaning no locks are held).  If this is
708 the situation, eventually it'll work itself out or get to a potential ping-pong
709 scenario.
710
711 2) When you change_to while handling preemption, once you start back up, you
712 will leave change_to and eventually fetch a new event.  This means any
713 potential ping-pong needs to happen on a fresh event.
714
715 3) If there are enough pcores for the vcores to all run, we won't issue any
716 change_tos, since the vcores are no longer preempted.  This means we only are
717 worried about situations with insufficient vcores.  We'll mostly talk about 1
718 pcore and 2 vcores.
719
720 4) Preemption handlers will not call change_to on their target vcore if they
721 are also the one STEALING from that vcore.  The handler will stop STEALING
722 first.
723
724 So the only way to get stuck permanently is if both cores are stuck doing a
725 sys_change_to(FALSE).  This means we want to become the other vcore, *and* we
726 need to restart our vcore where it left off.  This is due to some invariant
727 that keeps us from abandoning vcore context.  If we were to abandon vcore
728 context (with a sys_change_to(TRUE)), we basically don't need to be
729 preempt-recovered.  We already packaged up our cur_uthread, and we know we
730 aren't holding any locks or otherwise breaking any invariants.  The system will
731 work fine if we never run again.  (Someone just needs to check our messages).
732
733 Now, there are only two cases where we will do a sys_change_to(FALSE) *while*
734 handling preemptions.  Again, we aren't concerned about things like MCS-PDR
735 locks; those all work because the change_tos are done where we'd normally just
736 busy loop.  We are only concerned about change_tos during handle_vc_preempt.
737 These two cases are when the changing/handling vcore has a DONT_MIGRATE uthread
738 or when someone else is STEALING its uthread.  Note that both of these cases
739 are about the calling vcore, not its target.
740
741 If a vcore (referred to as "us") has a DONT_MIGRATE uthread and it is handling
742 events, it is because someone else is STEALING from our vcore, and we are in
743 the short one-shot event handling loop at the beginning of
744 uthread_vcore_entry().  Whichever vcore is STEALING will quickly realize it
745 can't steal (it sees the DONT_MIGRATE), and bail out.  If that vcore isn't
746 running now, we will change_to it (which is the purpose of our handling their
747 preemption).  Once that vcore realizes it can't steal, it will stop STEALING
748 and change to us.  At this point, no one is STEALING from us, and we move along
749 in the code.  Specifically, we do *not* handle events (we now have an event
750 about the other vcore being preempted when it changed_to us), and instead we
751 start up the DONT_MIGRATE uthread and let it run until it is migratable, at
752 which point we handle events and will deal with the other vcore.  
753
754 So DONT_MIGRATE will be sorted out.  Likewise, STEALING gets sorted out too,
755 quite easily.  If someone is STEALING from us, they will quickly stop STEALING
756 and change to us.  There are only two ways this could even happen: they are
757 running concurrently with us, and somehow saw us out of vcore context before
758 deciding to STEAL, or they were in the process of STEALING and got preempted by
759 the kernel.  They would not have willingly stopped running while STEALING our
760 cur_uthread.  So if we are running and someone is stealing, after a round of
761 change_tos, eventually they run, and stop STEALING.
762
763 Note that once someone stops STEALING from us, they will not start again,
764 unless we leave vcore context.  If that happened, we basically broke out of the
765 ping-pong, and now we're onto another set of preemptions.  We wouldn't leave
766 vcore context if we still had preemption events to deal with.
767
768 Finally, note that we needed to only check for one message at a time at the
769 beginning of uthread_vcore_entry().  If we just handled the entire mbox without
770 checking STEALING, then we might not break out of that loop if there is a
771 constant supply of messages (perhaps from a vcore in a similar loop).
772
773 Anyway, that's the basic plan behind the preemption handler and how we avoid
774 the ping-ponging.  change_to_vcore() is built so that we handle our own
775 preemption before changing (pack up our current uthread), so that we make
776 progress.  The two cases where we can't do that get sorted out after everyone
777 gets to run once, and since you can't steal or have other uthread's turn on
778 DONT_MIGRATE while we're in vcore context, eventually we clear everything up.
779 There might be other bugs or weird corner cases, possibly involving multiple
780 vcores, but I think we're okay for now.
781
782 3.10: Handling Messages for Other Vcores
783 ---------------------------------------
784 First, remember that when a vcore handles an event, there's no guarantee that
785 the vcore will return from the handler.  It may start fresh in vcore_entry().
786
787 The issue is that when you handle another vcore's INDIRs, you may handle
788 preemption messages.  If you have to do a change_to, the kernel will make sure
789 a message goes out about your demise.  Thus someone who recovers that will
790 check your public mbox.  However, the recoverer won't know that you were
791 working on another vcore's mbox, so those messages might never be checked.
792
793 The way around it is to send yourself a "check the other guy's messages" event.
794 When we might change_to and never return, if we were dealing with another
795 vcores mbox, we'll send ourselves a message to finish up that mbox (if there
796 are any messages left).  Whoever reads our messages will eventually get that
797 message, and deal with it.
798
799 One thing that is a little ugly is that the way you deal with messages two
800 layers deep is to send yourself the message.  So if VC1 is handling VC2's
801 messages, and then wants to change_to VC3, VC1 sends a message to VC1 to check
802 VC2.  Later, when VC3 is checking VC1's messages, it'll handle the "check VC2's messages"
803 message.  VC3 can't directly handle VC2's messages, since it could run a
804 handler that doesn't return.  Nor can we just forget about VC2.  So VC3 sends
805 itself a message to check VC2 later.  Alternatively, VC3 could send itself a
806 message to continue checking VC1, and then move on to VC2.  Both seem
807 equivalent.  In either case, we ought to check to make sure the mbox has
808 something before bothering sending the message.
809
810 So for either a "change_to that might not return" or for a "check INDIRs on yet
811 another vcore", we send messages to ourself so that we or someone else will
812 deal with it.
813
814 Note that we use TLS to track whether or not we are handling another vcore's
815 messages, and if we do plan to change_to that might not return, we clear the
816 bool so that when our vcore starts over at vcore_entry(), it starts over and
817 isn't still checking someone elses message.
818
819 As a reminder of why this is important: these messages we are hunting down
820 include INDIRs, specifically ones to ev_qs such as the "syscall completed
821 ev_q".  If we never get that message, a uthread will block forever.  If we
822 accidentally yield a vcore instead of checking that message, we would end up
823 yielding the process forever since that uthread will eventually be the last
824 one, but our main thread is probably blocked on a join call.  Our process is
825 blocked on a message that already came, but we just missed it. 
826
827 4. Single-core Process (SCP) Events:
828 ====================
829 4.1 Basics:
830 ---------------------------------------
831 Event delivery is important for SCP's blocking syscalls.  It can also be used
832 (in the future) to deliver POSIX signals, which would just be another kernel
833 event.
834
835 SCPs can receive events just like MCPs.  For the most part, the code paths are
836 the same on both sides of the K/U interface.  The kernel sends events (which
837 can detect an SCP and will send it to vcore0), the kernel will make sure you
838 can't yield/miss an event, etc.  Userspace preps vcore context in advance, and
839 can do all the things vcore context does: handle events, select thread to run.
840 For an SCP, there is only one thread to run.
841
842 4.2 Degenerate Event Delivery:
843 ---------------------------------------
844 That being said, there are a few tricky things.  First, there is a time before
845 the SCP is ready to fully receive events.  Specifically, before
846 vcore_event_init(), which is called out of glibc's _start.  More importantly,
847 the runtime linker never calls that function, yet it wants to block.
848
849 The important thing to note is that there are a few parts to event delivery:
850 registration (user), sending the event (kernel), making sure the proc wakes up
851 (kernel), and actually handling the event (user).  For syscalls, the only thing
852 the process (even rtld) needs is the first three.  Registration is easy - can be
853 done with nothing more than kernel headers (no need for parlib) for NO_MSG ev_qs
854 (no need to init the UCQ).  Event handling is trickier, and requires parlib
855 (which rtld can't link against).  To support processes that could register for
856 events, but not handle them (or even enter vcore context), the kernel needed a
857 few changes (checking the VC_SCP_NOVCCTX flag) so that it would wake the
858 process, but never put it in vcore context.  
859
860 This degenerate event handling just wakes the process up, at which point it can
861 check on its syscall.  Very early in the process's life, it'll init vcore0's
862 UCQ and be able to handle full events, enter vcore context, etc.
863
864 Once the SCP is up and running, it can receive events like normal.  One thing to
865 note is that the SCPs are not using a handle_syscall() event handler, like the
866 MCPs do.  They are only using the event to get the process restarted, at which
867 point their vcore 0 restarts thread0.  One consequence of this is that if a
868 process receives an unrelated event while blocking on a syscall, it'll handle
869 that event, then restart thread0.  Thread0 will see its syscall isn't complete,
870 and then re-block.  (It also re-registers its ev_q, which is harmless).  When
871 that syscall is finally done, the kernel will send an event and wake it up
872 again.
873
874 4.3 Extra Tidbits:
875 ---------------------------------------
876 One minor point: SCPs can't receive INDIRs, at least for now.  The kernel event
877 code short circuits all the fallback business and just spams vcore0's public
878 mbox.  If we ever change that, we need to be sure to post a notif_pending to
879 vcore0 (that's the signal to trigger a wakeup).
880
881 If we receive an event right as we transition from SCP to MCP, vcore0 could get
882 spammed with a message that is never received.  Right now, it's not a problem,
883 since vcore0 is the first vcore that will get woken up as an MCP.  This could be
884 an issue if we ever allow transitions from MCP back to SCP.
885
886 On a related note, it's now wrong for SCPs to sys_yield(FALSE) (not being nice,
887 meaning they are waiting for an event) in a loop that does not check events or
888 otherwise allow them to break out of that loop.  This should be fairly obvious.
889 A little more subtle is that these loops also need to sort out notif_pending.
890 If you are trying to yield and still have an old notif_pending set, the kernel
891 won't let you yield (it thinks you are missing the notif).  For the degenerate
892 mode, (VC_SCP_NOVCCTX is set on vcore0), the kernel will handle dealing with
893 this flag.
894
895 Finally, note that while the SCP is in vcore context, it has none of the
896 guarantees of an MCP.  It's somewhat meaningless to talk about being gang
897 scheduled or knowing about the state of other vcores.  If you're running, you're
898 on a physical core.  You may get unexpected interrupts, descheduled, etc.  Aside
899 from the guarantees and being the only vcore, the main differences are really up
900 to the kernel scheduler.  In that sense, we have somewhat of a new state for
901 processes - SCPs that can enter vcore context.  From the user's perspective,
902 they look a lot like an MCP, and the degenerate/early mode SCPs are like the
903 old, dumb SCPs.  The big difference for userspace is that there isn't a 2LS yet
904 (will need to reinit things slightly).  The kernel treats SCPs and MCPs very
905 differently too, but that may not always be the case.
906
907 5. Misc Things That Aren't Sorted Completely:
908 ====================
909 5.1 What about short handlers?
910 ---------------------------------------
911 Once we sort the other issues, we can ask for them via a flag in the event_q,
912 and run the handler in the event_q struct.
913
914 5.2 What about blocking on a syscall?
915 ---------------------------------------
916 The current plan is to set a flag, and let the kernel go from there.  The
917 kernel knows which process it is, since that info is saved in the kthread that
918 blocked.  One issue is that the process could muck with that flag and then go
919 to sleep forever.  To deal with that, maybe we'd have a long running timer to
920 reap those.  Arguably, it's like having a process while(1).  You can screw
921 yourself, etc.  Killing the process would still work.