Adds devalarm (#A)

It is an alarm service for processes.  Check out the top of
k/d/d/alarm.c and the test for more details.

Commented out right now, since we don't have a 9ns stack.
Userspace alarm service

Built off #A, this provides a basic alarm handler service similar to the
kernel's.  The main differences are that there are no semaphores and
only one tchain (interrupt source).

Instead of having to set up a full #A alarm for every little handler,
you can use the user alarm service, which will multiplex them in
userspace off a single kernel alarm.
Plan9 style waserror() handling

Adapted from the latest version we built for the old 9ns branch.

You'll need to #include err.h to use this.  Since it includes some other
files of its own, I didn't want to put it in common.h.
SYS_abort_syscall (XCC)

Userspace can request the cancellation of a syscall.  If that sysc is
blocked on a rendez, such as when listening on a network chan, it will
return via error().  If not, nothing will happen.

Reinstall your kernel headers.
Fixes bug with cross-core kernel alarms

Bad pointer arithmetic.
Fixes tchain corruption

If you have multiple unsets of the same waiter, you would corrupt the
list.  I actually had this happen, though I'm not sure how.  The ksched
alarm was getting accidentally ripped off this list, causing all
processes to hang.  My hunch is that ping was setting and cancelling
alarms frequently, and perhaps userspace submitted concurrent requests
to unset its main alarm.
Alarm to abort syscalls, should be used in ping

Will need to reorganize a lot of userspace's libraries.  Stuff like
nsec2tsc() doesn't need to be in a benchmarking library.  Same goes for
the alarm stuff; benchutil is more of a "everything I can't put in
parlib that we want by default."
Notes on using Go.

Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Fix for concurrent syscall aborters

And adds some explanation about the issues of aborting syscalls.
Massive amounts of notes paid off; they reminded me of the
multiple-aborter case.
Destroying procs will abort their syscalls

Will only abort the abortable syscalls, not ones blocked on qlocks or
anything other than a rendez_sleep().
Kernel alarms pass the alarm ID

So userspace can tell which of it's #A alarms is firing.  With this (and
with multiple event handlers per event), we could have multiple alarm
handlers register and run dynamically.  Alternatively, we could switch
based on the ID, if there was one common handler (can do that
statically).

Note that the existing alarm examples can receive multiple events for
the same alarm.  It's up to userspace to handle that (it's easy, and we
do it).  This is a consequence of using SPAM_PUBLIC.  If your alarm
can't handle that, use an INDIR/FALLBACK.  This is part of the reason
why I didn't make a helper to set up all the alarm stuff - people will
want to customize, especially in the realm of the ev_q.  (The other
issue is whether or not CLOEXEC is used.  And there may be other issues
I haven't thought of).

Multiple ev_qs can be registered for different alarms; it's just hard to
share the event handler for them all, hence this patch.  I'll deal with
this more if we ever get someone who wants to use multiple kernel alarms
with different handlers.
Fixes ktask aborting

For some reason, my original testing machine didn't catch this.  proc can be
non-zero, but still gibberish, causing a PF.
Fix the top level makefile

If your .config included more than on kfs path, and any of those
paths did not exist, empty directories were created. Fix that.

Fix the logic up a bit on creating the image such that
you have some idea that a directory in your paths does
not exist.

Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Hack for qemu's missed LAPIC timers

If your system hangs and needs keyboard input (or network packets) to
wake up, try turning on LOUSY_APIC_TIMER, and report your results to the
mailing list.  We've seen this on qemu with KVM disabled.

Here's part of the email with details from debugging this:

------------------------------
> still, the question is whether or not __trigger was sitting there as
> an RKM while we halted the core, or if the timer IRQ didn't fire
> until we hit the KB.  i'll poke around a bit - i should be able to
> check the RKM queue from qemu.

turns out that we don't have any pending RKMs when everything is
halted (looked at the memory from qemu), which means the timer interrupt
isn't going off (since it should enqueue an RKM).  then once we hit a
key (like CTRL-Q), the timer interrupt does fire before the KB/serial
IRQ; we see the RKM __trigger_tchain queued (via the monitor/kfunc).

so it looks like the timer IRQ should fire, but doesn't.  and then when
we fire some other IRQ, like serial/KB, the timer IRQ does fire.  i
haven't been able to inspect the LAPIC from qemu - that's not the sort
of thing they'd emulate in physical memory for the monitor, i guess.

anyway, perhaps qemu with-no-kvm doesn't like something about our local
apic timer IRQs?  since qemu doesn't report an always running APIC, it's
possible for the timer to stop in deep C states or speedstep
transitions (SDM 3a 10.5.4).  though even when we -enable-kvm, qemu
also reports no "always running APIC."  maybe qemu is getting confused
and turning something off, or i screwed up some initialization?  Or
perhaps qemu doesn't like our use of "hlt", and has some race of it's
own where halt and alarms happen concurrently.

whenever we do break it out (via KB, for instance), we actually get two
IRQs delivered (handle_irq() runs twice from the moment i hit ctrl-q
til we get into the monitor (which happens directly from ctrl-q's IRQ
handler)).  so probably the first IRQ is the LAPIC timer, and the second
is the keyboard.

incidentally, any IRQ, not just a keyboard/serial IRQ, is enough to
break qemu out of its funk.  so instead of holding down the space bar
with a power supply, you can keep trying to telnet to localhost:5555.
=)
Makefile can detect changes in alternate KFS dirs

If we don't have kfs-paths as the source of kern_initramfs_files, make
probably won't notice the change to files in any directory other than
FIRST_KFS_PATH, and thus it won't rebuild KFS with the updated files.

This change can detect missing directories too, though you'll need to
run make a couple times if you recently had a bad KFS paths list, due to
how we don't process the .config right away.
Cleans up tests/

We're making a lot of old tests that we don't need, and they all
bloat the size of the initramfs.  This cuts it from 48MB to 26MB or so,
for me.  Glibc still takes up 13MB.

Part of the reason each test is large (200KB+) is that they all
statically link parlib.

All of the tests still live in an old/ directory.  Feel free to add more
tests, in general.  Anything we'll regularly use can be in the main
tests/ directory.  I'm just tired of building (and copying across the
network) huge kernel images.

You might need to make userclean.

You'll also want to clean out binaries from kern/kfs/bin, since those
won't get automatically cleaned.  To do this, I mv'd busybox out of KFS
temporarily, then did:

$ find kern/kfs/bin -type f -exec rm '{}' \+

(or something similar) to remove the binaries, but not the symlinks for
busybox.  Then I mv'd busybox back.
Fixes AMD cpuinfo MSR problem

Broader problem: some MSRs are Intel specific, some aren't.  We call all
of them IA32_.  This patch only access two known-bad MSRs if we think we
are Intel.  The MISC_ENABLE was crashing AMD boxes.  FEATURE_CONTROL
hasn't crashed anything yet, but I don't see it in the AMD manual.
Add a line of info to the Go docs

Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Fix race with x86 boot

It's possible that some IRQ could break the AP cores out of their halt
before core 0 set up things for the final core init.
Dirty hack for serial I/O on Ron's AMD

Hopefully this will go away very soon.  We're not getting serial IRQs,
so we poll whenever another IRQ (timer) goes off.