akaros.git
7 days agoUnmap pages mapped during a failed fill_vmr() master origin/master current
Barret Rhoden [Wed, 6 Nov 2019 18:25:25 +0000 (13:25 -0500)]
Unmap pages mapped during a failed fill_vmr()

If we get part of the way through filling the VMR with the parent's
contents, but then run out of memory, we were leaving the old,
successful PTE mappings behind.  The VMR would be freed and never
added to the proc's list, so we wouldn't unmap it during __proc_free().
However, our assert would catch that the process still has mapped pages
that weren't a part of any VMR.

I'm not 100% that this is what happened with syzkaller, but it's a
likely scenario, especially since other bugs it found recently are due
to running low/out of memory.

Reported-by: syzbot+28ec6ca66d7b660fbf4d@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
7 days agoHandle ENOMEM during fork()
Barret Rhoden [Wed, 6 Nov 2019 18:21:37 +0000 (13:21 -0500)]
Handle ENOMEM during fork()

Reported-by: syzbot+638411bd4594d01e2d70@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 weeks agovmm: reimplement the x86 instruction decoder test origin/test
Barret Rhoden [Wed, 23 Oct 2019 22:56:05 +0000 (18:56 -0400)]
vmm: reimplement the x86 instruction decoder

Our old decoder had a bunch of issues.  Whenever we get a new version of
Linux, we tend to have new instructions that need decoding.  The old
decoder was hard to extend, and it was also hiding a bunch of bugs.

Here are some of the problems the old decoder had:
- It assumed every operation was a load or store.  Including cmp (which
does not change registers/memory) and add (which does change them, but
only after adding).
- It did not set rflags
- It did not zero-extend 32-bit wide register results
- *word was busted.  At one point, we did word++ when we meant to
advance by a byte.
- etc.

The code was pretty 'swirly' too, where you'd have similar processing
repeated all over the place, like the REX checks.

To fix that, I added a 'decode' struct, to pass along values that we
determined, such as address size, operand size, rex bits, etc.

Best of all, we weren't computing the size correctly, since we didn't
really do the modrm handling right.  Here's the case:

81 7d 00 5f 4d 50 5f    cmp    DWORD PTR [rbp+0x0],0x5f504d5f

That was being treated like it is only 4 bytes long, instead of 7.
Whoops!

However, it didn't crash, even though we set RIP to be part way (4
bytes) into the instruction!  Why?  well, those extra three bytes that
are just arbitrary numbers in the immediate32 part of the instruction
(which we end up running) decodes too!

0:  4d 50                   rex.WRB push r8
2:  5f                      pop    rdi

It pushes and pops, essentially clobbering rdi.  The Linux guest ends up
resetting rdi later, so no one noticed.

Had it been another value for the immed, we'd execute that too.  It
might blow up, and we'd notice.  But this one silently executed and
silently trashed a register.

To fix that, I needed better mod/rm+sib handling.  We still get away
with using GPA instead of decoding modrm+sib and translating through the
guest's page tables.  Ron's comment still applies.  =)

To handle the emulation of instructions, I had our callers pass us the
'access()' function.  So we can handle read-modify-write instructions,
like add.  Those didn't need to change too much, though I yanked out
destreg, which was just debug clutter.

I could have broken the commit up a little bit, but there wasn't a lot
of value in it, since the whole thing needed to be overhauled.

Note that the APIC_ACCESS and WRITE exits never happen.  That might have
been the case ever since we started using the x2APIC for the guest.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 weeks agox86: add FL_STATUS (XCC)
Barret Rhoden [Wed, 23 Oct 2019 22:34:14 +0000 (18:34 -0400)]
x86: add FL_STATUS (XCC)

Helpful for our x86 decoder.

Reinstall your kernel headers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agox86: clean up MSI handlers and vectors
Barret Rhoden [Tue, 8 Oct 2019 21:08:17 +0000 (17:08 -0400)]
x86: clean up MSI handlers and vectors

With this change, drivers can deregister their IRQs, shut down their
devices, and reinitialize them.

Tested with MSI-X, but not MSI.  The IOAT device I have for testing is
MSI-X only.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agox86: use a proper allocator for IRQ vectors
Barret Rhoden [Tue, 8 Oct 2019 21:00:23 +0000 (17:00 -0400)]
x86: use a proper allocator for IRQ vectors

Yet another arena allocator!

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agox86: msi: refactor pci_msi_enable()
Barret Rhoden [Tue, 8 Oct 2019 18:22:30 +0000 (14:22 -0400)]
x86: msi: refactor pci_msi_enable()

Pulled out the setting-of-the-addr-and-data into its own function, and
clarified the difference between msi_ready and msix_ready.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agox86: add deregister_irq()
Barret Rhoden [Mon, 7 Oct 2019 20:12:52 +0000 (16:12 -0400)]
x86: add deregister_irq()

It's about as good as register_irq().

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agox86: use RCU to protect the IRQ handlers list
Barret Rhoden [Mon, 7 Oct 2019 19:37:22 +0000 (15:37 -0400)]
x86: use RCU to protect the IRQ handlers list

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agox86: return the irq_handler from register_irq()
Barret Rhoden [Mon, 7 Oct 2019 19:12:13 +0000 (15:12 -0400)]
x86: return the irq_handler from register_irq()

register_irq() is a mess.  This helps a little - at least the caller can
determine the vector assigned.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoRemove the KADDR check from pahexdump()
Barret Rhoden [Tue, 8 Oct 2019 21:01:32 +0000 (17:01 -0400)]
Remove the KADDR check from pahexdump()

We're hexdumping physical memory.  Just hexdump the damn thing.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agodma: rewrite DMA allocations with arenas and KMCs
Barret Rhoden [Tue, 1 Oct 2019 14:04:34 +0000 (10:04 -0400)]
dma: rewrite DMA allocations with arenas and KMCs

A dma_pool is now just a slab allocator on top of a struct dma_arena.
These allocators provide device-accessible memory *allocations*.  You
can still 'DMA-map' kernel memory for drivers.  This is just for the
Linux DMA alloc APIs, for now.

The reason for some of the kpages->paddr->kaddr acrobatics is I want to
support address spaces other than physical and kernel virtual.
Specifically, I'd like to try to keep a driver in the kernel, but with
the device operating in the user's address space, i.e. behind an IOMMU.
In that sense, the driver *code* is like a syscall in the user's address
space, and the device is like a processor in Ring 3.  We'll see.

Eventually, we could make all of our drivers use these, and perhaps sort
out how to do DMA pinning with the same sense of device addresses.

If it turns out this is a horrible idea, we can make the dma_pool just
pull from kpages and be done with all the to_cpu_addr() translations.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoslab: free the expanded hash table
Barret Rhoden [Thu, 3 Oct 2019 21:02:24 +0000 (17:02 -0400)]
slab: free the expanded hash table

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: add __arena_create() and __arena_destroy()
Barret Rhoden [Wed, 2 Oct 2019 18:47:02 +0000 (14:47 -0400)]
arena: add __arena_create() and __arena_destroy()

These are lower level interfaces where the caller handles memory.  If
you want any half-way usable self-sourced arena, you're going to embed
it in another struct, and container_of() to that struct in the arena
alloc/free funcs.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: check for imports when destroying
Barret Rhoden [Wed, 2 Oct 2019 18:30:50 +0000 (14:30 -0400)]
arena: check for imports when destroying

This catches bugs where we tear down an arena while other arenas or
slabs still depend on it.  It's the equivalent of a use-after-free.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: allow "self-sourced" arenas
Barret Rhoden [Wed, 2 Oct 2019 16:52:10 +0000 (12:52 -0400)]
arena: allow "self-sourced" arenas

These arenas generate their own resources dynamically and arbitrarily.
They do not source from another arena, such as base, but they also are
not given their segments in advance with arena_add().  Instead, they
create resources when asked.

It is similar to calling arena_add() in response to a failed allocation,
except the allocation never fails.

The arena alloc function pointer lets you do whatever you want.  The
reason for self-sourcing instead of pulling from a dummy arena is that
the self-source provides a pointer to the arena in the allocation
function.  With that pointer, you now have your original arena, which
could be embedded in another structure.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoslab: trigger allocation failure for failed ctors
Barret Rhoden [Mon, 30 Sep 2019 19:13:42 +0000 (15:13 -0400)]
slab: trigger allocation failure for failed ctors

We were just returning NULL, which would have MEM_WAIT allocs return
NULL.  It'd usually panic immediately - this way we catch it a little
earlier in a common path.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoslab: warn about duplicated KMC names when tracing
Barret Rhoden [Mon, 30 Sep 2019 18:42:53 +0000 (14:42 -0400)]
slab: warn about duplicated KMC names when tracing

Instead of during creation.  The IOAT driver creates a KMC call
'completion_pool' for every device.  I'm not going to bother giving them
separate names.  The only thing we used duplicate names for was
debugging and slab_trace.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: fix qcache double-free
Barret Rhoden [Mon, 30 Sep 2019 18:08:12 +0000 (14:08 -0400)]
arena: fix qcache double-free

This was nasty.  The qcache would be freed twice, which meant that it
would get reused twice.  It resulted in the full_slab_list having weird
shit on it: it looked like a SLIST of magazines!

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoslab: add __kmem_cache_destroy()
Barret Rhoden [Fri, 27 Sep 2019 15:22:26 +0000 (11:22 -0400)]
slab: add __kmem_cache_destroy()

Like __kmem_cache_create(), it operates on a KC whose memory is managed
by the caller.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: add arena tests
Barret Rhoden [Thu, 26 Sep 2019 16:40:07 +0000 (12:40 -0400)]
arena: add arena tests

And some details about the difference between qcaches and regular slab
allocators.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoslab: use a singly-linked list for bufctls
Barret Rhoden [Wed, 25 Sep 2019 20:17:53 +0000 (16:17 -0400)]
slab: use a singly-linked list for bufctls

It saves a pointer for each bufctl.

I glanced at arena.c for the same thing.  The code for those
FOREACH-remove_if_X are a little more involved, but not a big deal.  But
the big one is untrack_free_seg, which isn't called from a list-foreach.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoslab: don't assume allocations succeed
Barret Rhoden [Wed, 25 Sep 2019 19:51:38 +0000 (15:51 -0400)]
slab: don't assume allocations succeed

A couple places assumed a MEM_ATOMIC allocation would succeed.  You can
tell they are old places since they still passed '0' for a flag.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoslab: fix alignment issues
Barret Rhoden [Mon, 16 Sep 2019 16:19:57 +0000 (12:19 -0400)]
slab: fix alignment issues

This clarifies many of the issues around alignment and source quantum.

Previously, there were a lot of assumptions about source alignment
(assumed PGSIZE, but it was actually quantum), object size (assumed big
enough for a pointer), etc.  If you had an arena with quantum > PGSIZE
and made a slab / KC from it (e.g. a qcache), you'd trip the assertion
too.

We also didn't have any guarantees about carrying a source's
quantum-multiple-alignment through to the slab, which matters for
non-power-of-two sources that want to use qcaches.  We use the "if
obj_size is a multiple of quantum, you'll get quantum-multiple-aligned
allocations" guarantee to solve the problem for qcaches.

Slab align is a separate item from both arena quantum and arena align.
The object we get from a source gets aligned up (or is already the right
alignment, for the pro-touch/non-bufctl case), which requires us to
track the original address from the arena in the slab.  That's fine.
Might as well use that for the pro-touch case.

I considered getting rid of PGSIZE, but its usage in obj->slab lookups
is pretty handy.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: fix xalloc minaddr|maxaddr
Barret Rhoden [Tue, 24 Sep 2019 16:23:27 +0000 (12:23 -0400)]
arena: fix xalloc minaddr|maxaddr

Two problems:
- if you had a single segment that contained minaddr, we'd skip that
segment and start with the *next* one.  Not only did this mean we
skipped a perfectly good segment that could have had the fix, but we
might not have a *next* segment, causing an OOM / failure.

The fix was to find the BT that contained minaddr, not just the strict
upper bound.  This means we need to handle the case where BT contains
minaddr: hence try_start and try_size.

- We'd scan the list of all nodes starting from the upper bound (and now
equality), regardless of whether or not they are free.  Yikes!

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: allow a nocross xalloc() with a source arena
Barret Rhoden [Fri, 13 Sep 2019 20:48:51 +0000 (16:48 -0400)]
arena: allow a nocross xalloc() with a source arena

When we need to import segments from a parent arena to satisfy an
xalloc, we need to make sure that a successful import actually satisfies
the xalloc.

This doesn't seem easily solvable for min/maxaddr, short of pushing the
xalloc all the way down the chain or having some other inter-arena
interface.  But it should be solvable for nocross, by getting a large
enough allocation.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoAdd a helper for least common multiple
Barret Rhoden [Mon, 23 Sep 2019 20:17:29 +0000 (16:17 -0400)]
Add a helper for least common multiple

For one number being a power of two.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: fix __arena_add() quantum alignment issue
Barret Rhoden [Mon, 16 Sep 2019 15:38:31 +0000 (11:38 -0400)]
arena: fix __arena_add() quantum alignment issue

__arena_add() was asserting that the span we were adding was quantum
'aligned.'  However, our source gives us allocations according to *its*
quantum, not our quantum.  If our source was e.g. bytes and we give out
pages, then our source could give us a span that does not match our
quantum.

This is fine, albeit a source of fragmentation.  We just make sure our
arena's bt tracks the object we want (on a quantum boundary and a
multiple of quantum).  span_bt will track whatever we actually got from
our source.

Another note: ALIGNED() checks on quantum were currently wrong - there's
nothing in the arena code that forced quantum to be a power of two.  At
least, I didn't see it, and don't want to restrict us to that yet.
Though we'll likely have issues with align, non-aligned quantums, and
qcaches.  For instance, if you ask for a quantum of 3, with an align of
64, the qcaches were told to do an align of 3 (quantum).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: let the kernel call kmemstat()
Barret Rhoden [Tue, 24 Sep 2019 14:48:57 +0000 (10:48 -0400)]
arena: let the kernel call kmemstat()

For debugging.  The user's interface is #mem/kmemstat.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: destroy qcaches when destroying arenas
Barret Rhoden [Mon, 23 Sep 2019 23:50:12 +0000 (19:50 -0400)]
arena: destroy qcaches when destroying arenas

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena/slab: warn when destroying unfreed items
Barret Rhoden [Mon, 23 Sep 2019 23:36:11 +0000 (19:36 -0400)]
arena/slab: warn when destroying unfreed items

Instead of panicking.  This leaks resources, but keeps the machine
running.  It's a little hokey, since any attempt to free the objects
will run into issues.  Though if someone forgot to free it, hopefully
they won't free it before we can use the machine for some last minute
diagnostics.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoslab: remove magazines from lists in depot_destroy()
Barret Rhoden [Mon, 23 Sep 2019 23:24:03 +0000 (19:24 -0400)]
slab: remove magazines from lists in depot_destroy()

This never worked - if there were any magazines, we'd keep on looping
until we crashed.  It'd be nice if there was a BSD SLIST_POP_FIRST() or
something.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: warn instead of panic for free-checks
Barret Rhoden [Mon, 23 Sep 2019 20:29:15 +0000 (16:29 -0400)]
arena: warn instead of panic for free-checks

These checks are signs of bugs, but we can proceed by just returning.
For the size-mismatch, we could try and free the correct size, but since
there is some bug, we should be safe and just not free anything.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: allow freeing NULL
Barret Rhoden [Mon, 23 Sep 2019 20:27:26 +0000 (16:27 -0400)]
arena: allow freeing NULL

This is a convenience for test code.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: do not round-up when picking xalloc lists
Barret Rhoden [Mon, 23 Sep 2019 20:20:32 +0000 (16:20 -0400)]
arena: do not round-up when picking xalloc lists

The list we start at is an optimization.  We could easily start at the
first list.  We skip to the first list that *can* satisfy us.
Previously, due to align and phase acrobatics, we could jump to the next
list beyond the one that could satisfy us, which could lead to an "OOM"
when we actually had the resource.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: use the entire imported span
Barret Rhoden [Fri, 13 Sep 2019 21:27:58 +0000 (17:27 -0400)]
arena: use the entire imported span

The source arena will round up to its quantum.  However, we would only
know that we got 'import_size', but we might get far more than that from
the parent.  If we round-up in advance, we'll know how much we are
getting.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: fix btag freeing in arena_destroy()
Barret Rhoden [Fri, 20 Sep 2019 15:14:56 +0000 (11:14 -0400)]
arena: fix btag freeing in arena_destroy()

We are freeing the btags, not the objects they point to.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoarena: make 'name' a const char *
Barret Rhoden [Mon, 16 Sep 2019 19:12:21 +0000 (15:12 -0400)]
arena: make 'name' a const char *

I'd like to build an arena from Linux code, which tends to use 'const
char*' more aggressively than we did.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoInclude linux/overflow.h and sys/types.h in all files
Barret Rhoden [Fri, 13 Sep 2019 20:23:42 +0000 (16:23 -0400)]
Include linux/overflow.h and sys/types.h in all files

Just about every C file needs types.h, and I'd like the overflow checks
to be as easy as builtins.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoAdd shortened integer typedefs
Barret Rhoden [Fri, 13 Sep 2019 20:19:03 +0000 (16:19 -0400)]
Add shortened integer typedefs

This adds typedefs such as u64 for uint64_t.

I got tired of needing to run spatch and changing Linux code as much.
From now on, you can use whichever you'd like in the kernel, especially
if the code came from another project.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoAdd overflow.h from Linux
Barret Rhoden [Fri, 13 Sep 2019 18:26:07 +0000 (14:26 -0400)]
Add overflow.h from Linux

v5.2.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoscripts: handle kernel backtraces with bt-akaros.sh
Barret Rhoden [Fri, 13 Sep 2019 15:15:02 +0000 (11:15 -0400)]
scripts: handle kernel backtraces with bt-akaros.sh

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoioat: port the IOAT driver
Barret Rhoden [Fri, 30 Aug 2019 19:52:34 +0000 (15:52 -0400)]
ioat: port the IOAT driver

Passes the self-test.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoioat: spatch the IOAT driver
Barret Rhoden [Mon, 26 Aug 2019 18:22:40 +0000 (14:22 -0400)]
ioat: spatch the IOAT driver

for i in scripts/spatch/linux/*.cocci
do
./scripts/spatch/spatch-me.sh $i yes kern/drivers/dma/ioat/
done

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoioat: import the IOAT driver from Linux
Barret Rhoden [Mon, 26 Aug 2019 18:19:02 +0000 (14:19 -0400)]
ioat: import the IOAT driver from Linux

From drivers/dma/ioat/, Linux 5.2.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agodma: port Linux's dmaengine
Barret Rhoden [Wed, 28 Aug 2019 20:05:49 +0000 (16:05 -0400)]
dma: port Linux's dmaengine

There are no users or devices yet.  This compiles and runs the
initialization code.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agodma: spatch Linux's dmaengine files
Barret Rhoden [Tue, 27 Aug 2019 19:14:36 +0000 (15:14 -0400)]
dma: spatch Linux's dmaengine files

Ran the scripts in scripts/spatch/linux/:
funcs.cocci  io_funcs.cocci  memory.cocci  scalar.cocci  sync.cocci

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agodma: import dmaengine from Linux
Barret Rhoden [Tue, 27 Aug 2019 19:13:14 +0000 (15:13 -0400)]
dma: import dmaengine from Linux

From Linux 5.2.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoPort Linux's sizes.h
Barret Rhoden [Wed, 28 Aug 2019 20:54:07 +0000 (16:54 -0400)]
Port Linux's sizes.h

This is a minor change.  Right now we don't need this header in
assembly, and likely won't, so it's simpler to just change the header
than to import const.h and uapi/const.h.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoAdd Linux's sizes.h
Barret Rhoden [Wed, 28 Aug 2019 20:52:09 +0000 (16:52 -0400)]
Add Linux's sizes.h

From 5.2.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agoAdd Linux's circ_buf.h
Barret Rhoden [Wed, 28 Aug 2019 20:23:54 +0000 (16:23 -0400)]
Add Linux's circ_buf.h

From 5.2.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agospatch: add a few features to the Linux coccis
Barret Rhoden [Fri, 30 Aug 2019 19:36:10 +0000 (15:36 -0400)]
spatch: add a few features to the Linux coccis

Notably, the lock transform was mismatched.  We'd set all locks to be
irqsave (by the init function), but the _bh locks were not irqsave.

The issue here is that _bh locks *don't* need to be irqsave, but we
don't know when we look at spinlock_init where the lock is grabbed.  At
least not easily.  So since we say all locks are irqsave, we need to be
consistent.

Another option would be to keep them as spin_lock_bh and #define it, so
we keep the info that it is a bh lock.  Or if we really care about a
slightly lower lock in a Linux driver, we just look at the changelog.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agospatch: fix Linux's typedef coccis
Barret Rhoden [Fri, 27 Sep 2019 16:29:48 +0000 (12:29 -0400)]
spatch: fix Linux's typedef coccis

You need to tell spatch about typedefs that aren't part of C.  'int' is
fine.  'uint32_t' is not.  I'm not sure if this worked before, or if
more recent versions of spatch started to fail for it.  The Plan 9
cocci files were fine.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agomlx4: do not set struct device * to NULL
Barret Rhoden [Fri, 4 Oct 2019 19:23:40 +0000 (15:23 -0400)]
mlx4: do not set struct device * to NULL

This driver was ported back before we had any struct device in
pci_device.  We don't use it for much, but I can use it to find the
pci_device for a given Linux driver's device.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 weeks agopci: rename device->linux_dev
Barret Rhoden [Thu, 29 Aug 2019 15:07:03 +0000 (11:07 -0400)]
pci: rename device->linux_dev

We have dev_id, which is Linux's device.  We had device, which was
Linux's dev.  We also have 'dev', which is encoded in Linux's devfn.
This was a mess, especially since when we spatched dev to device, that
collided with other uses of device (meaning dev_id) in Linux.

Anyway, we aren't even using linux_dev nee device, it was just a source
of confusion for me.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
6 weeks agoRework the Linux-compat timer code
Barret Rhoden [Fri, 30 Aug 2019 19:32:33 +0000 (15:32 -0400)]
Rework the Linux-compat timer code

Our alarm code is mostly sufficient to do the things Linux's timers do.
The old code was unable to cancel timers and was just a huge hack.  This
is just a moderate hack.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
6 weeks agomlx4: use setup_timer()
Barret Rhoden [Fri, 30 Aug 2019 19:30:22 +0000 (15:30 -0400)]
mlx4: use setup_timer()

Instead of setting things by hand.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
6 weeks agoalarm: do not wait for unset when resetting an alarm
Barret Rhoden [Fri, 30 Aug 2019 19:17:00 +0000 (15:17 -0400)]
alarm: do not wait for unset when resetting an alarm

reset_alarm_* are racy.  Concurrent resetters can both unset, then both
set, and set_alarm can't be called on an alarm that is already set.

Right now, the only thing going for reset_alarm is that it makes sure
the alarm has stopped before we set it again.  That seems to prevent the
race between reset_alarm for the handler and an external function, but
does nothing for the race between two random functions.

But actually, the handlers can't call reset_alarm (prior to this
commit); unset will block on the handler finishing, which is a deadlock.
(cv_wait->can_block will catch this).

Basically, handlers needed to use set_alarm to rearm, since they know
they aren't on the tchain anymore.  Hokey.  set_alarm works outside a
handler too (and not the old __set_alarm vs set_alarm nonsense), but
that's only for when you know a handler isn't armed.

A lot of code wants to use reset_alarm, which is similar to Linux's
mod_timer.  It's better to have all of those functions callable in any
context - particularly the most useful one.

This commit doesn't fix the race between unset and set yet.  Instead,
has us unset without waiting for the handler to finish before setting.
This makes it usable in alarm handlers.  You may then worry - can't this
alarm get rearmed and run on another tchain (cpu) concurrently, and then
we're racing on alarm state?  No - if the alarm was currently running,
it was presumably on the same tchain that we're putting it on -
otherwise the caller was bugged.  If it's on the same tchain, then we're
OK, since we know a given tchain processes alarms in order.

A note on naming issues: nosync vs sync, and what's the default can get
sorted out in a future commit.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
6 weeks agoAdd a few Linux compatibility shims
Barret Rhoden [Wed, 28 Aug 2019 20:04:49 +0000 (16:04 -0400)]
Add a few Linux compatibility shims

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
6 weeks agoMake linker function declarations a tag
Barret Rhoden [Wed, 28 Aug 2019 18:13:07 +0000 (14:13 -0400)]
Make linker function declarations a tag

This is similar to Linux's initcall().  Instead of changing the name of
the function, just tag it.  This makes it a little easier to port Linux
drivers too.

The __init tag does nothing right now.  For now, just use it as a
convention.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
6 weeks agoRename the __percpu section
Barret Rhoden [Wed, 28 Aug 2019 17:46:42 +0000 (13:46 -0400)]
Rename the __percpu section

__percpu is used by Linux to tag percpu code.  I'd like to keep those
tags when porting Linux drivers and possibly use those tags in the
future.  There's no reason to not change the section name.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
6 weeks agox86: clean up MSI(X) output format
Barret Rhoden [Fri, 30 Aug 2019 19:50:02 +0000 (15:50 -0400)]
x86: clean up MSI(X) output format

The new version is more clearly a BDF and removes the confusing
'msivec', which was the hardware field.

Note that we print the irq_h->name, but no one actually sets that...
Everything related to register_irq(), including msix setup, needs a lot
of work.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
6 weeks agoslab: add kmem_cache_zalloc()
Barret Rhoden [Wed, 28 Aug 2019 20:40:43 +0000 (16:40 -0400)]
slab: add kmem_cache_zalloc()

You could argue that the caller could do this with a ctor, though it
depends on when we run the ctors.  Do we cache constructed objects in
magazines?  I'd guess 'yes', without a lot of thought, so then each
separate allocation wouldn't be zeroed.

The other reason to make a separate function for this is that it's
easier to just implement it.  We have the object size in the kc, but the
ctor function pointer actually *doesn't* have that info, so we'd need to
pass it through.  Minor pain, chance to mess it up, etc.

The other other reason is that Linux has this function.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
6 weeks agocbdma: skip initializing any PCI devices
Barret Rhoden [Fri, 30 Aug 2019 19:40:58 +0000 (15:40 -0400)]
cbdma: skip initializing any PCI devices

In lieu of using the Linux IOAT driver, we don't want to muck with the
same PCI device another driver is using.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agovmm: refactor userspace's emsr_fakewrite()
Barret Rhoden [Thu, 22 Aug 2019 18:46:45 +0000 (14:46 -0400)]
vmm: refactor userspace's emsr_fakewrite()

The old fakewrite would attempt to do a readmsr, which will fail.
However, we only need to do a readmsr if we read before writing.  Most
uses of this will do a write first.

Note that rdmsr and wrmsr will fail from userspace.  The MSR emulation
code is mostly just an unused copy of the kernel's, but it's useful to
prototype changes in userspace without requiring a kernel reboot.  i.e.
this is for debugging.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agovmm: x86: allow guests to poke MSR_IA32_PRED_CMD (XCC)
Barret Rhoden [Thu, 22 Aug 2019 18:40:53 +0000 (14:40 -0400)]
vmm: x86: allow guests to poke MSR_IA32_PRED_CMD (XCC)

This is the Indirect Branch Predictor Barrier (IBPB).  Writing to it
similar to a cache flush, in that there are no effects or settings that
persist in the processor, such that we would be worried about letting
the guest use the same MSR as the kernel.

Guests who detect support for IBPB in CPUID may try and use this MSR on
context switches.  Letting them do so is harmless.  In the future, if we
decide to pretend to be a different processor or otherwise lie about
CPUID values, then this would be a mechanism for guests to detect IBPB
support.

Reinstall your kernel headers if you want to use the MSRs from
userspace, such as in vmxmsr.c.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agoiommu: add documentation
Aditya Basu [Sat, 17 Aug 2019 01:46:52 +0000 (21:46 -0400)]
iommu: add documentation

Signed-off-by: Aditya Basu <mitthu@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agoiommu: populate functions for setup/teardown of page tables
Aditya Basu [Sat, 17 Aug 2019 01:00:56 +0000 (21:00 -0400)]
iommu: populate functions for setup/teardown of page tables

* setup_page_tables(): add pci_device to a proc's addr space
* teardown_page_tables(): remove pci_device from the proc's addr space

Signed-off-by: Aditya Basu <mitthu@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agoiommu: add support for iotlb shootdowns and write-buffer flushing
Aditya Basu [Sat, 17 Aug 2019 01:00:03 +0000 (21:00 -0400)]
iommu: add support for iotlb shootdowns and write-buffer flushing

* Add fields to struct iommu which are set during initialization
* Add the necessary functions
* Will also need another function to perform global iotlb flushes
* Also look into Queue Invalidation (QI) for device IOTLBs. Currently we
  do not allow device IOTLBs to be populated. For device IOTLBs we need
  to set the TRANS_TYPE to 0x01.

Signed-off-by: Aditya Basu <mitthu@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agoiommu: add essential functionality
Aditya Basu [Sat, 17 Aug 2019 01:16:51 +0000 (21:16 -0400)]
iommu: add essential functionality

* Files
    * power: enable/disable at runtime
    * attach: attach pci device to pid
    * detach: write the pci device to detach from process (verify valid
      pid is writing to it for security?)
    * mappings: prints current pid <=> device(s) mappings
    * info: print driver info and all live register values

* Assert capabilities and set iommu->supported
    * Assert super pages
    * Assert pass-through capable (in context entries)
    * Assert 4-level paging
    * Assert unique rba

* A struct iommu is declared for each IOMMU on the system.
* Default DID=1 because DID=0 is reserved if caching mode is set
  in IOMMU capabilities. Due to this disallow pid=1 from attaching any
  devices.

* Paging structures and helpers
    * Construct the root table (bus) and context table (dev + func)
    * Mark all PCI devices as pass through in context table. This allows
      devices to continue to address host physical memory.
    * IOMMU is turned on by default with no actual translation (pass
      through mode).

* acpi.c: hook in to initialize all discovered IOMMUs
    * Embed struct iommu in struct Drhd
    * Print the addr of iommu struct associated with the DRHD. This is
      shown in #acpi/pretty.
    * Initialize the iommu during DMAR initialization
    * Add helper iommu_supported()
    * Add helper iommu_initialize_global() and iommu_initialize() for
    calling from acpi.c

* pci.c: Associate struct pci_device with struct iommu
    * Add proc_owner field to struct pci_device
    * Iterate over all PCI devices and assign the correct IOMMU. For now
      we assign the default IOMMU to all PCI device. So PCI devices
      under scoped IOMMUs (if reported by DRHD) will not work correctly.

Signed-off-by: Aditya Basu <mitthu@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agoiommu: cleanup intel-iommu.h
Aditya Basu [Thu, 15 Aug 2019 20:53:46 +0000 (16:53 -0400)]
iommu: cleanup intel-iommu.h

* Remove all Linux related functions and headers
* Add necessary macros to make it usable

Signed-off-by: Aditya Basu <mitthu@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agoiommu: import "linux/intel-iommu.h" from Linux v5.1
Aditya Basu [Mon, 29 Jul 2019 20:20:53 +0000 (16:20 -0400)]
iommu: import "linux/intel-iommu.h" from Linux v5.1

Signed-off-by: Aditya Basu <mitthu@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agoucbdma: userspace cbdma test
Aditya Basu [Sat, 17 Aug 2019 01:14:16 +0000 (21:14 -0400)]
ucbdma: userspace cbdma test

* Creates a ring buffer of a single descriptor.
* The copy buffers are placed in low memory in the same descriptor page.
* Takes a pcidev as argument and instructs the IOMMU to passthru that
device.

Signed-off-by: Aditya Basu <mitthu@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agocbdma: add documentation
Aditya Basu [Sat, 17 Aug 2019 01:45:41 +0000 (21:45 -0400)]
cbdma: add documentation

Signed-off-by: Aditya Basu <mitthu@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agocbdma: add support for Intel CBDMA/IOAT
Aditya Basu [Sat, 17 Aug 2019 01:51:56 +0000 (21:51 -0400)]
cbdma: add support for Intel CBDMA/IOAT

* Creates #cbdma device and a minimal hierarchy with files:
    ktest - run the self-test
    stats - dump register values and driver information
    reset - write 1 to reset the cbdma
    iommu - turn on/off IOMMU support

* Search through all PCI devices and looks for the following devices.
If any device is found, then only a single function is registered.
    * Vendor ID: 0x8086, Device ID: 0x2021 (Skylake)
    * Vendor ID: 0x8086, Device ID: 0x2f20 (Haswell)
* If no cbdma device is found then the device will not attach (bind).

* The PCI bar registers pages are re-mapped with nocache
* A desc chain is populated which describes the DMA transfers
* On MSI interrupts, the driver acks the interrupts and re-enables
interrupts

* User-Space CDMA (ucbdma)
    * desc addresses are converted to kaddr and issued (IOMMU = off)
    * desc addresses are not-converted to kaddr (IOMMU = on)

Signed-off-by: Aditya Basu <mitthu@google.com>
[minor formatting touchups]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agopci: add domain identifier
Aditya Basu [Fri, 16 Aug 2019 16:40:03 +0000 (12:40 -0400)]
pci: add domain identifier

- Add identifier for PCI domain.
- The field is declared as "int"; refer Linux source:
include/asm-x86_64/pci.h
- Legacy domain field used to be 16-bits.

Signed-off-by: Aditya Basu <mitthu@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agopci: add mmio addr to #pci ctl files
Aditya Basu [Fri, 16 Aug 2019 16:34:07 +0000 (12:34 -0400)]
pci: add mmio addr to #pci ctl files

Before:
    $ cat /dev/pci/0.4.0ctl
    8.80.0 8086/2021  11 0:0x 16384

After:
    $ cat /dev/pci/0.4.0ctl
    8.80.0 8086/2021  11 0:0x    0/febf0000 16384

The mmio_base32 and mmio_base64 physical address mappings are now
printed. If the device is dma64 capable then it gets mapped to
mmio_base64 as is the case above. The PCI device information shown above
is for Intel CBDMA.

Signed-off-by: Aditya Basu <mitthu@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
2 months agogit: track the specific branch only
Barret Rhoden [Mon, 19 Aug 2019 16:37:14 +0000 (12:37 -0400)]
git: track the specific branch only

No tags, no other branches.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 months agoacpi: handle machines with no MCFG
Barret Rhoden [Wed, 14 Aug 2019 16:24:53 +0000 (12:24 -0400)]
acpi: handle machines with no MCFG

Syzkaller died during early boot after ACPI init and before/during PCI.
It's likely the VM it runs in doesn't have an MCFG, and we weren't
handling that case when PCI queried a device's MMIO config space.

Reported-by: syzbot+3feb100d5398d8b5d728@syzkaller.appspotmail.com
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 months agopci: add support for MMIO config space
Barret Rhoden [Wed, 14 Aug 2019 15:30:15 +0000 (11:30 -0400)]
pci: add support for MMIO config space

MMIO config space has two benefits: it does not require the global PCI
lock, and it easily works with extended PCI config space (i.e. above 255).

For whatever reason, I had an old note that said you could use PIO for
the extended config space.  I probably got that from looking at Linux or
something.  It might have worked on some older machines for me; I don't
recall.  But it certainly does not work with all machines.  Maybe it was
an AMD/Intel thing.

I left support for PIO in case we run into a weird machine that doesn't
have the ACPI MCFG table or for debugging.  Though even my QEMU has an
MCFG.  We can remove it if it is a pain - maybe when we make PCI more
architecture-independent.  Right now it is x86-specific, both in PIO and
MMIO ops.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 months agopci: rename pci_{read,write}{8,16,32} accessors
Barret Rhoden [Tue, 13 Aug 2019 21:40:34 +0000 (17:40 -0400)]
pci: rename pci_{read,write}{8,16,32} accessors

These config space accessors are for PIO, and the new names make their
functionality more clear.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 months agopci: remove PIO pci_{read,write}{8,16,32} declarations
Barret Rhoden [Tue, 13 Aug 2019 21:35:27 +0000 (17:35 -0400)]
pci: remove PIO pci_{read,write}{8,16,32} declarations

The port-mapped IO interface to PCI config space is only used in pci.c.
We want to allow MMIO PCI config space too, and we don't want other
files using the PIO internal functions.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 months agoacpi: parse the MCFG table
Barret Rhoden [Wed, 14 Aug 2019 15:24:22 +0000 (11:24 -0400)]
acpi: parse the MCFG table

The MCFG table describes the location of MMIO config space for PCI
devices.  The PCI subsystem can query ACPI to get a particular device's
config space physical address.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agovmm: remove more verbose output
Barret Rhoden [Tue, 9 Jul 2019 18:28:26 +0000 (14:28 -0400)]
vmm: remove more verbose output

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agoalarm/cons/eventfd/random: improve tap errstr message
Barret Rhoden [Thu, 20 Jun 2019 15:43:27 +0000 (11:43 -0400)]
alarm/cons/eventfd/random: improve tap errstr message

It's nice to know what the attempted tap was.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agoinit: make #srv creatable when bound at /srv
Barret Rhoden [Wed, 19 Jun 2019 16:39:52 +0000 (12:39 -0400)]
init: make #srv creatable when bound at /srv

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agotests: fix the return value of bind, srv, and stat
Barret Rhoden [Fri, 14 Jun 2019 21:55:53 +0000 (17:55 -0400)]
tests: fix the return value of bind, srv, and stat

Return 0 on success.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agotmpfs: fix non-unique instance bug
Barret Rhoden [Fri, 14 Jun 2019 19:22:35 +0000 (15:22 -0400)]
tmpfs: fix non-unique instance bug

tmpfs cleans itself up when it disappears.  QIDs within an instance were
unique, starting from 0.  However, QIDs *between* instances were not
unique!  Multiple instances would be separate TFSs, but they were
reusing QIDs.

Where's the problem with that?  Walk and whatnot happen in the tree file
code.  Don't forget about mount/bind!  If you bind another device onto a
tmpfs file, then other tmpfs instances in your namespace will also have
that device mounted!  For example:

cd -P \#tmpfs
mkdir pipe-or-whatever # QID 1
/bin/bind \#pipe pipe-or-whatever
cd / # destroys tmpfs

cd -P \#tmpfs # new tmpfs
ls pipe-or-whatever # still bound!

Someone else could be the one that saw that too.  Any file with that QID
(e.g. a file, not a directory) could also have that bind!  That's
because the namespace mount-detecting code uses chan equality, which is
qid.path equality (within a device) (for the most part - also checks
type (directory/file/etc)).

The fix is to have unique instances of tmpfs, and encode that in the
QID.  You have to put it in the path, not the vers, since all callers of
eqchan() that we care about are 'pathonly', meaning they don't care
about the version.

I used an arena to exercise the code a bit.  A u16_pool would be
simpler.  Though it doesn't have a destructor (yet).  Arguably we should
only use the u16_pool when performance is important, if at all.  That's
only used in #mnt.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months ago9ns: properly set dir->type and dir->dev for fs_files
Barret Rhoden [Fri, 14 Jun 2019 19:17:28 +0000 (15:17 -0400)]
9ns: properly set dir->type and dir->dev for fs_files

We were not setting the type and dev.  Type is the struct devtab's
number identifying the device.  Dev is the device-specific subsystem;
often 0.

You can see type when you do a stat.  That dir->type field shows up as
'dev' in stat.  Gotta love the conversions.

The effect of this is that you can now stat devices that are TFSs, e.g.
KFS, tmpfs, and get a sensible device.  Previously, you'd just get '0',
which is some other device.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months ago9ns: remove chandev{reset,init,shutdown}()
Barret Rhoden [Fri, 14 Jun 2019 19:15:48 +0000 (15:15 -0400)]
9ns: remove chandev{reset,init,shutdown}()

These are basically the same as devtab{reset,init,shutdown}().

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months ago9ns: remove unused device shutdown methods
Barret Rhoden [Fri, 14 Jun 2019 19:13:06 +0000 (15:13 -0400)]
9ns: remove unused device shutdown methods

devshutdown() is the one that does nothing.  kprof and vers had their
own empty functions, which was just confusing when I went looking for
devices that had shutdown methods.

Note that we never call shutdown, and all of the shutdown/reset/init
stuff isn't well understood.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agoarena: catch bad spans containing '0'
Barret Rhoden [Fri, 14 Jun 2019 19:07:44 +0000 (15:07 -0400)]
arena: catch bad spans containing '0'

Currently arena's can't hand out the value '0'.  That's actually baked
in to the vmem interface.  NULL is returned on error, so you can't
differentiate between it and 0.  I'm OK with that for now.

The asserts will catch people who try to add a span starting at 0, which
is close enough to catch this problem.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agouth: add got_posix_signal() to the 2LS ops
Barret Rhoden [Thu, 13 Jun 2019 20:32:41 +0000 (16:32 -0400)]
uth: add got_posix_signal() to the 2LS ops

How we handle a POSIX signal is very 2LS-specific.  Thread0 can easily
abort syscalls for its only thread.  Pthreads can call pthread_kill.
The VMM-2LS can route signals to specific task threads.

This commit moves the default logic into 2LS-specific ops.  VMM and
pthreads keep the old behavior.  Thread0 gets behavior more similar to
what the shells want: interrupt their syscall.  It also doesn't need to
use a fake context.

To some extent, the 2LS just needs to pick a thread, and then we
trigger_posix_signal() and/or abort the syscall.  Whether or not those
all need to happen, or whether we need to provide a context to the
threads, is currently 2LS dependent.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agoAllow SYS_waitpid to be aborted
Barret Rhoden [Thu, 13 Jun 2019 20:26:53 +0000 (16:26 -0400)]
Allow SYS_waitpid to be aborted

This is useful for shells that want to abort a waitpid in response to a
signal.  Both busybox and bash expect their waitpid calls to return in
response to a signal.

We probably can rewrite the wait code to use rendezes instead of CVs,
and then we'd get aborting for free.  As it stands, it's not too hard to
build it in.  The should_abort() check actually covers the old 'is
dying' check, which is nice.

The ugliest thing is that wait_one and wait_any are very similar.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agobb: do not clobber the bash symlink
Barret Rhoden [Thu, 13 Jun 2019 20:21:52 +0000 (16:21 -0400)]
bb: do not clobber the bash symlink

This gets confusing when working with both busybox and bash, as most of
our systems do.  If you install busybox after bash, such as by cd
tools/apps/busybox; make, then /bin/bash -> busybox.

It seems nice to have the bash symlink get covered by busybox, but then
again, on Akaros, the #!/bin/bash line doesn't get handled by the
kernel.  The shells just run the script internally, so they don't
handler the interpreter line.  Parlib doesn't even do it - it runs
"/bin/sh WHATEVER."

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agoMake 'ps' not report itself
Barret Rhoden [Wed, 12 Jun 2019 22:03:30 +0000 (18:03 -0400)]
Make 'ps' not report itself

This has been an irritant for a very long time.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agovmm: net: use the MAC to signal the networking style
Barret Rhoden [Wed, 12 Jun 2019 21:07:33 +0000 (17:07 -0400)]
vmm: net: use the MAC to signal the networking style

Our NAT has the ability to emulate the 10.0.2.x network, where the guest
is .15 and the host/router is .2.  It can also use 'real addresses',
where the guest thinks it has the host's IP.

It's hard for the guest to know which type of network it is on until it
gets a DHCP response.  Those can be slow (relatively), and VM appliances
that use networking at all want to use a static config.

This commit uses the lowest byte of our synthetic virtio-net MAC address
to tell the guest which style of networking is present.  Suitably
coupled guest startup scripts can check the MAC address, detect the
10.0.2.x network, and statically configure themselves.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 months agovmm: add AKAROS_VMCALL_SHUTDOWN (XCC)
Barret Rhoden [Wed, 12 Jun 2019 21:06:45 +0000 (17:06 -0400)]
vmm: add AKAROS_VMCALL_SHUTDOWN (XCC)

Guests can use this vmcall to ask to be shutdown / powered off.

Reinstall your kernel headers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 months agoFix chan memory leak in sysopenat()
Barret Rhoden [Wed, 12 Jun 2019 16:34:26 +0000 (12:34 -0400)]
Fix chan memory leak in sysopenat()

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
5 months agoSupport O_CREATE with SYS_openat
Barret Rhoden [Wed, 12 Jun 2019 16:27:56 +0000 (12:27 -0400)]
Support O_CREATE with SYS_openat

Previously, we would attempt a sysopenat(), then when it failed, do
syscreate().  However, the syscreate() can't handle an 'at' FD.  The
file would be created in the current directory, as if it was a normal
open.

The simplest thing was to push the O_CREATE fallback business into
openat itself.  That cleaned up the syscall.c code, and eventually will
lead to the removal of syscreate().  Currently, it is still used by
mkdir, which also cannot handle 'at' FDs.

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