tree 068608091c518a867549fde49e4e768dc721ba2f
parent 0362326de13b4934887b58cb95d868604881c648
author Barret Rhoden <brho@cs.berkeley.edu> 1483730383 -0500
committer Barret Rhoden <brho@cs.berkeley.edu> 1484006500 -0500

Allow larger CEQs (XCC)

Previously, the user may have been punished for having a very large CEQ
event space.  This is the range of possible event IDs the CEQ would ever
see.  For FDs, technically the user might want NR_FILE_DESC_MAX (2^19).
That'd be about a 16 MB CEQ structure, and an O(2^19) recovery scan.

With this change, we only grow the CEQ's actual memory use on demand (soft
page fault) and only scan up to the max ever seen.  The memory tricks are
OK - the kernel needs to protect against PFs when accessing user memory
anyways, and it is safe for vcore context to have a soft PF on anonymous
memory.  (If we're OOM, we'd need to handle that regardless of whether or
not the user happened to be in vcore context).

Rebuild the world.  (At least glibc and dropbear.  Probably anything
multicore too).

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