akaros.git
3 years agoFix DOTDOT for #root
Barret Rhoden [Wed, 31 Aug 2016 10:43:59 +0000 (06:43 -0400)]
Fix DOTDOT for #root

devroot is a mess.  I think it can't grow dynamically very well.  There
are already well-known issues (in the TODO section).

For now, this allows us to do something like "ls /env/..".  Previously
that would crash.  I took it a step farther and added subdirectories to
env, just to make sure DOTDOT worked for non-root DOTDOTs.  That was a
huge pain.

Now you can do things like this without crashing the kernel:

/ $ ls /nvfs/../
chan     env      mnt      net.alt  proc     prog     srv
dev      fd       net      nvfs     prof     root
/ $ ls /env/
env_dir1  env_dir2
/ $ ls /env/../
chan     env      mnt      net.alt  proc     prog     srv
dev      fd       net      nvfs     prof     root
/ $ ls /env/env_dir2/../
env_dir1  env_dir2

We used to have some code that would, for when we weren't at the
top-of-device entry (e.g. ""), appear to walk all siblings of
roottab[p], until we found the one whose qid.path matched whatever we
found via rootdata[].dotdot.  That seemed busted.

Ultimately, we need a dynamically changeable ramfs.  #root might not be
it.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoStop using snprintf in write_hex_to_fd (XCC)
Barret Rhoden [Tue, 23 Aug 2016 21:28:56 +0000 (17:28 -0400)]
Stop using snprintf in write_hex_to_fd (XCC)

This is somewhat of a stopgap to deal with a brutal bug.  VM guests were
seeing XMM corruption.  Eventually, we boiled down to a simple test that
even showed the host task thread's xmm state was getting corrupted.  We
noticed that printf calls (used in debugging) were clobbering the xmm
state, which stands to reason: most any glibc string or memory operation
uses xmms.  Check out strrchr, strlen, and memcmp.

It's quite legal for any function to use xmm state - we're supposed to save
it before clobbering it.  The problem comes with vcore context.  If vcore
context calls any of these functions, including snprintf, it can clobber FP
state.  Unlike other functions, vcore context is not supposed to do that.

The specific scenario was that the VMM 2LS's vcore timer tick would fire.
When we reenabled the vcore tick, we'd ultimately call write_hex_to_fd,
which would use snprintf.  That would clobber the FPU state, which was the
guest's state.

The long term fix is to either aggressively save and restore FP state in
vcore context or ensure that no glibc helpers use xmms when we're in vcore
context.  The choice will probably depend on how expensive the FP
save/restores are on x86.  Fixing the glibc helpers would be a minor pain;
we'd need our own sysdep, but we'd still want to call the xmm version
during non-vcore-context.  That also doesn't protect us from any other apps
that might try to call an xmm op during an event handler.

So in that regard, it's a stopgap.  I also like not relying on glibc in
general from vcore context, so the less snprintfs for simple things, the
better.

Rebuild glibc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix num_to_nibble()
Barret Rhoden [Tue, 23 Aug 2016 21:12:05 +0000 (17:12 -0400)]
Fix num_to_nibble()

If you passed it a negative number, the mod wouldn't take the lower 4 bits.
I originally went with % 16 so it'd be clear we're dealing with 16
characters in the array.  That needed to be unsigned.  While I'm here, I'll
just do the masking too, in case this code gets copied and morphed a bit.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdd basic SO_ERROR support (XCC)
Barret Rhoden [Tue, 30 Aug 2016 18:20:30 +0000 (14:20 -0400)]
Add basic SO_ERROR support (XCC)

Dropbear checks SO_ERROR to see if there was a problem.  We currently don't
track errors at the socket layer, but we can at least say there was no
issue.  In the future, we can extend the Rock/socket shims to track recent
errors if we want.

Rebuild glibc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAHCI: re enable the PCI device.
Ronald G. Minnich [Tue, 23 Aug 2016 22:05:34 +0000 (15:05 -0700)]
AHCI: re enable the PCI device.

This is not strictly an AHCI thing but I needed it for
AHCI debugging. It's been in our tree for a long time and
it was time to turn it on.

Usage:
/bin/bind -a '#pci' /dev

bash-4.3$ ls /dev/pci
0.0.0ctl   0.2.0ctl   0.25.0ctl  0.29.0ctl  0.5.0ctl   1.0.0ctl   6.0.0ctl
0.0.0raw   0.2.0raw   0.25.0raw  0.29.0raw  0.5.0raw   1.0.0raw   6.0.0raw
0.1.0ctl   0.20.0ctl  0.26.0ctl  0.3.0ctl   0.5.1ctl   1.0.1ctl
0.1.0raw   0.20.0raw  0.26.0raw  0.3.0raw   0.5.1raw   1.0.1raw
0.17.0ctl  0.22.0ctl  0.28.0ctl  0.31.0ctl  0.5.2ctl   5.0.0ctl
0.17.0raw  0.22.0raw  0.28.0raw  0.31.0raw  0.5.2raw   5.0.0raw

The raw file is the config space; the ctl file is operations.

This is inherently safer than what we've done to date using
direct IO to the 0xcf8/cfc addresses, as they are shared
resources and multiple users can interfere with each other
(which has been seen in the nature).

Change-Id: I54e2f0e9af1361bfd8aebf0d7094d2a749f6065b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
[checkpatch fixes]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoUse getopt_long and add help option to vmrunkernel
Kyle Milka [Wed, 24 Aug 2016 23:35:43 +0000 (16:35 -0700)]
Use getopt_long and add help option to vmrunkernel

Added getopt_long to vmrunkernel, now there are less cryptic names for
some of the available option. Also, no longer have to go inspect the source
to figure out which options you need.

Change-Id: I305a075e9c49a7412b706f767cde6ad29dd235fb
Signed-off-by: Kyle Milka <kmilka@google.com>
[checkpatch touchups]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoVMM: Add commandline parameter to force use of TSC
Gan Shun [Wed, 24 Aug 2016 23:34:38 +0000 (16:34 -0700)]
VMM: Add commandline parameter to force use of TSC

The VM guest was turning off the TSC after using watchdog.
We tell it to use the tsc regardless. This is due to us not handling
the lapic timer properly.

Fixes: b/30568132

Signed-off-by: Gan Shun <ganshun@gmail.com>
Change-Id: I7640ee2578ac7fb1c63b60b46fc279f78172fa2d
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoMMIO: make mmio operators type safe.
Ronald G. Minnich [Mon, 22 Aug 2016 15:12:29 +0000 (08:12 -0700)]
MMIO: make mmio operators type safe.

The operators took void *, which made it extremely
hard to debug incorrect usage, which I had a lot of
in the ahci driver. They are now type safe, e.g.
a write to a byte requires a uint8_t*, not a void *.

Change-Id: I089a8f3c5d71fcbc3250535e47e998ee3c15f08e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
[mlx4 recast, checkpatch fixups]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix shifting bug in radix_insert()
Barret Rhoden [Fri, 19 Aug 2016 19:57:18 +0000 (15:57 -0400)]
Fix shifting bug in radix_insert()

This failed to index for keys greater than 32 bits.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix offset calculation in populate_va
Barret Rhoden [Fri, 19 Aug 2016 19:55:05 +0000 (15:55 -0400)]
Fix offset calculation in populate_va

That should clearly be a +, not a -, since we're figuring out how far into
the VMR to map.

This would trigger if you had a file mmapped that wasn't MAP_POPULATE, then
had a uthread fault on accessing that file, and it wasn't on the first page
of the file.

While we're here, we can also catch any integer overflows with offset and
length.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoBuild gcc with USE_PT_GNU_EH_FRAME (XCC)
Barret Rhoden [Fri, 19 Aug 2016 17:40:52 +0000 (13:40 -0400)]
Build gcc with USE_PT_GNU_EH_FRAME (XCC)

If we don't build with PT_GNU_EN_FRAME set, our shared libraries (e.g.
libm.so) will have a dependency on unwinding, which can get erronously
linked with libgcc_eh.a's hidden __register_frame_info.

Those references would come from frame_dummy(), called from _init.  On
Linux, this doesn't happen, and we attempt to be as similar to Linux as
possible, at least regarding the toolchain.

Note that USE_PT_GNU_EH_FRAME is not set when CRTSTUFFT_0 is set.  That is
explicitly set when building with -static.  That makes some sense, since
static apps will link against libgcc_eh.a (and not libgcc_s.so), and the
dynamic apps will use the PT_GNU_EH_FRAME.

There's some info on this stuff here:

http://www.airs.com/blog/archives/166

Rebuild your toolchain.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdded GNU `tar` to Akaros.
Dan Cross [Wed, 17 Aug 2016 15:22:18 +0000 (11:22 -0400)]
Added GNU `tar` to Akaros.

Change-Id: I04a71cffdfac2eea2f424616a5bcfbd7f0b34956
Signed-off-by: Dan Cross <crossd@gmail.com>
[moved to app-arch]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdd GNU `cpio` to Akaros.
Dan Cross [Wed, 17 Aug 2016 15:22:11 +0000 (11:22 -0400)]
Add GNU `cpio` to Akaros.

Change-Id: I2710a25a4e48604a8c44a90734447d22ec0e95c6
Signed-off-by: Dan Cross <crossd@gmail.com>
[moved to app-arch]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdd GNU `diffutils` for Akaros.
Dan Cross [Wed, 17 Aug 2016 15:21:48 +0000 (11:21 -0400)]
Add GNU `diffutils` for Akaros.

Change-Id: I292616827359fde95fde313034794e040eb72ad4
Signed-off-by: Dan Cross <crossd@gmail.com>
[typo in gitignore]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoSched_getcpu should return vcoreid. (XCC)
Dan Cross [Thu, 18 Aug 2016 19:30:23 +0000 (15:30 -0400)]
Sched_getcpu should return vcoreid. (XCC)

sched_getcpu implements a Unixy interface; to a first order
approximation, Unix would only know about what we would think
of as a 'vcore': Unix and Linux view the world as if they
provide a virtual layer around the *entire* computer, but
Akaros's MCP is not like that: it's a subset of the machine.

Anyway, hide the pcore ID from the legacy interface: if someone
wants to do something esoteric where they need to know the pcore
ID they can use parlib directly.

Change-Id: I9627c9c1d6b21282cd07b24b30c097f4d3726748
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoSpecify nic via commmand line
Kyle Milka [Tue, 16 Aug 2016 21:21:04 +0000 (14:21 -0700)]
Specify nic via commmand line

You can now specifiy the nic to use with the -n option.

Change-Id: I39c4384953798f4f9eb43057300037c4934d7f4f
Signed-off-by: Kyle Milka <kmilka@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoDisallow one-liner functions in clang-format.
Christopher Koch [Mon, 15 Aug 2016 23:54:54 +0000 (16:54 -0700)]
Disallow one-liner functions in clang-format.

Change-Id: I3e9884b3eaf05c4a7fdb718e76697f28f15d40b9

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoPrint PID in segfault default signal handler. (XCC)
Christopher Koch [Mon, 15 Aug 2016 20:35:42 +0000 (13:35 -0700)]
Print PID in segfault default signal handler. (XCC)

Rebuild glibc.

Change-Id: I5cb6a833b9f8b5a2409607e795834e18a34a0758
Signed-off-by: Christopher Koch <chrisko@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoReduce mmap calls in vfprintf.c (XCC)
Barret Rhoden [Fri, 12 Aug 2016 22:07:46 +0000 (18:07 -0400)]
Reduce mmap calls in vfprintf.c (XCC)

It turns out that the work_buffer path gets called a lot, including by
bash.  I saw a lot of mmaps in a few traces.  I think we can put that 1k on
the stack, since it's right near the magic number of 1/4 of a minimum
stack size.  We'll see.

This also fixes the other mmap, which should have been asking for
MAP_ANONYMOUS.

Rebuild glibc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoUse a constructor in benchutil/alarm
Barret Rhoden [Fri, 12 Aug 2016 20:50:39 +0000 (16:50 -0400)]
Use a constructor in benchutil/alarm

It's possible to race with multiple threads (or vcore context) setting up
awaiters at the same time.  The nicer approach, and one that avoids a lot
of work in vcore context, is to use a constructor.

Programs that *might* call the alarm code (thus link and trigger the
constructor) will pay the setup tax (opening FDs, etc), instead of delaying
that setup cost until when we *know* they will use the alarms.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoIncrease the alloca cutoff (XCC)
Barret Rhoden [Fri, 12 Aug 2016 20:41:39 +0000 (16:41 -0400)]
Increase the alloca cutoff (XCC)

Turns out that 128 is too small, and some programs can trigger it quite
easily.

Rebuild glibc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoRemove set_awaiter_abs() from the user interface
Barret Rhoden [Thu, 11 Aug 2016 18:24:55 +0000 (14:24 -0400)]
Remove set_awaiter_abs() from the user interface

To avoid future confusion.  Long term, we'll probably use nsec since boot
globally.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix timeout bug in semaphores
Barret Rhoden [Thu, 11 Aug 2016 18:19:39 +0000 (14:19 -0400)]
Fix timeout bug in semaphores

set_awaiter_abs() takes TSC ticks, not microseconds.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAHCI: reformat with clang-format, fix with spatch.
Ronald G. Minnich [Thu, 11 Aug 2016 17:08:45 +0000 (10:08 -0700)]
AHCI: reformat with clang-format, fix with spatch.

This did require changes to typedef.cocci but that will
come in a different patch.

Change-Id: I30f64d91c9bdc789a620db08b10fce384c6843fe
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoCoreutils for Akaros.
Dan Cross [Thu, 11 Aug 2016 16:41:35 +0000 (12:41 -0400)]
Coreutils for Akaros.

Add a Makefile and patchset to build coreutils for Akaros.

Note that we hack the Makefile to fake manpage generation,
as this requires running the output of the freshly-built
commands through 'help2man'. But since those commands target
Akaros, they won't run on the build machine (which will
typically run some sort of POSIXy operating system like
Linux).

Change-Id: Icf3e17107184a4b024582e41063e251fe1b07880
Signed-off-by: Dan Cross <crossd@gmail.com>
[ added a gitignore ]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAHCI initial commit.
Ronald G. Minnich [Tue, 9 Aug 2016 22:24:31 +0000 (15:24 -0700)]
AHCI initial commit.

From github.com:harvey-os/harvey 5be5d9cc0a1da28339c61e974c31b1915d2a1b03

Change-Id: I5cd052ce7bde5f6eb6de9557dfe6151174d1ef5f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoCheck for size==1 before rounding to power of two in epoll init.
Dan Cross [Wed, 10 Aug 2016 17:43:15 +0000 (13:43 -0400)]
Check for size==1 before rounding to power of two in epoll init.

While technically 1==2^0 is a power of two, the ROUNDUPPWR2
was changing the size of the epoll set to 2 before we tested
for two; since this set does not grow, we were getting errors
trying to add low-value FDs to the set, causing errors.

Slightly rearranging the order in which we do these operations
fixes this.

Change-Id: I2d068416941e8e1e9d7cfa98d56f5ea5b159802b
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoKick the VMM 2LS when enqueueing a thread
Barret Rhoden [Fri, 5 Aug 2016 00:39:11 +0000 (17:39 -0700)]
Kick the VMM 2LS when enqueueing a thread

Previously, we'd only run the 2LS logic on sched_entry().  If you
created threads and didn't do something triggering sched_entry(), such
as uthread_sleep_forever(), any system call, take a notify/IPI, etc,
then we'd never run that logic and you could deadlock.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAllow vcore_tick_* to be called from uthreads
Barret Rhoden [Fri, 5 Aug 2016 00:34:19 +0000 (17:34 -0700)]
Allow vcore_tick_* to be called from uthreads

Previously, they were designed for use from sched_entry(), and thus
vcore context.  There are cases where scheduler functions that aren't in
vcore context might want to mess with the *current vcore's* timer tick.

To do this, I had to stop using the TLS variable, and use a constructor
instead.  Otherwise, the uthread would use its own __vc_tick.  When a
uthread disabled notifs, it appears to be in vcore context to other
vcores and the kernel.  However, it is not actually in vcore context, at
least when it comes to TLS and stacks.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoCouldn't actually wrap around the vring.
Kyle Milka [Mon, 8 Aug 2016 18:28:38 +0000 (11:28 -0700)]
Couldn't actually wrap around the vring.

This check didn't allow the vring to actually wrap around, if the next
available index was less than the last index, it caused the error to be
triggered.

Change-Id: I90c26cfd894a9b729e44937e1894ce5bfbf1d144
Signed-off-by: Kyle Milka <kmilka@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoImport patch to fix shell script/exit status bug.
Dan Cross [Fri, 5 Aug 2016 20:09:58 +0000 (16:09 -0400)]
Import patch to fix shell script/exit status bug.

Import patch from the bash maintainers: Chet Ramey provided
this fix for the bug we observed some time ago.

Change-Id: I412151e27436fe88adf9507700dd488bd6334d7b
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoRewrite /bin/pci into bash.
Dan Cross [Thu, 4 Aug 2016 21:42:48 +0000 (17:42 -0400)]
Rewrite /bin/pci into bash.

As per Ron's request, this is Harvey's /rc/bin/pci recast as a
'bash' script and made to work with Akaros's '#pci' device.

Change-Id: I46a66155014acaf486270f504ee2e559c8fe33c9
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoImport /rc/bin/pci from Harvey.
Dan Cross [Thu, 4 Aug 2016 21:42:47 +0000 (17:42 -0400)]
Import /rc/bin/pci from Harvey.

As per Dr. Minnich's request. This is the original from Harvey; it
is an 'rc' script.

Change-Id: If7e4014c87bbd5a9d7a7fc9989c23394ee2743c3
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix-up command line files
Kyle Milka [Thu, 4 Aug 2016 18:42:14 +0000 (11:42 -0700)]
Fix-up command line files

There were a few errors in these files, it will be easier to
just have the correct version upstream.

Change-Id: I3ecb6bec4837d92d58cc7230d0afd1c7a5bde34a
Signed-off-by: Kyle Milka <kmilka@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix multiple setting in DTLS
Barret Rhoden [Wed, 3 Aug 2016 23:14:30 +0000 (16:14 -0700)]
Fix multiple setting in DTLS

The bug was that __get_dtls was returning a v->dtls, not a v.  Thus if
we set twice, we'd dereference the *value*, instead of v.  In essence,
we'd set v->dtls->dtls = dtls.  That's a wild write.

Incidentally, our DTLS handles set/get calls from within the destructor
without resorting to infinite loops, PTHREAD_DESTRUCTOR_ITERATIONS (4)
retries, or other nasty shit.  Nicely done, Kevin.  =)

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoReformat DTLS
Barret Rhoden [Wed, 3 Aug 2016 22:52:14 +0000 (15:52 -0700)]
Reformat DTLS

Did clang format, plus a bunch of things it didn't handle:

- block comments weren't wrapped
- functions with no arguments were not of the "void foo(void)" style
- no empty lines after local parameter declarations
- some trailing whitespace

It also moved around the include order.  Hopefully that didn't break
anything.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdd a couple features to .clang_format
Barret Rhoden [Wed, 3 Aug 2016 22:51:21 +0000 (15:51 -0700)]
Add a couple features to .clang_format

This should do the "tabs for indentation, spaces for alignment"
formatting and should detect common for-loop macros.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix the license on certain Parlib files
Barret Rhoden [Wed, 3 Aug 2016 21:49:27 +0000 (14:49 -0700)]
Fix the license on certain Parlib files

These came from the Linux version of Parlib.  Technically, this changes
them from v3 to v2, since Linux-Parlib was v3.  I checked with Kevin and
he said this was fine.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix inb when linux tests for the PIC
Gan Shun [Thu, 4 Aug 2016 17:45:18 +0000 (10:45 -0700)]
Fix inb when linux tests for the PIC

Previously we clobbered bits 63:8 of RAX when responding to this inb.
This is not technically correct. We now only change the low 8 bits.

Signed-off-by: Gan Shun <ganshun@gmail.com>
Change-Id: Iacb0c72cbbb0b4dfa229824c19ba4b000177e567
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdd instruction decode for a few more specific instructions
Gan Shun [Thu, 4 Aug 2016 17:45:17 +0000 (10:45 -0700)]
Add instruction decode for a few more specific instructions

We don't want to turn this into a full instruction decoder, so there are
just a few hardcoded added cases to handle certain move instructions
that we see.

Signed-off-by: Gan Shun <ganshun@gmail.com>
Change-Id: I0c51251232b27e2d33ffe2c0a30bacafe233f6af
[minor formatting]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdd page table walk for guest va to pa translation
Gan Shun [Thu, 4 Aug 2016 17:45:16 +0000 (10:45 -0700)]
Add page table walk for guest va to pa translation

We used to assume that the gpa would be the same as the gva minus the
high order bits. That is not the case for some kernels. This actually
walks the page table that the guest sets up to find the correct gpa.

Signed-off-by: Gan Shun <ganshun@gmail.com>
Change-Id: Ieed65f23476dc2c5e9e882ef5599870b3758565b
[minor formatting]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix MSR emulation to hide Intel functionality that we don't support
Gan Shun [Thu, 4 Aug 2016 17:45:15 +0000 (10:45 -0700)]
Fix MSR emulation to hide Intel functionality that we don't support

We report 0 for perf capabilities because we don't want to support perf
tools yet, and we report 0 for MCG to prevent linux from trying to setup
machine checks.

Signed-off-by: Gan Shun <ganshun@gmail.com>
Change-Id: Ieef80e16536a8448a570b69342e4a58ef82b15f0
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix VM Guest CPUID emulation to hide VMX
Gan Shun [Thu, 4 Aug 2016 17:45:14 +0000 (10:45 -0700)]
Fix VM Guest CPUID emulation to hide VMX

We report no VMX capabilities to the VM guest we're running as we don't
currently support nested VMs.

Signed-off-by: Gan Shun <ganshun@gmail.com>
Change-Id: Ie90bea3c255a95df0dad6c9f5b58055431029b02
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix wonky tail queue swap in condition variables code.
Christopher Koch [Wed, 3 Aug 2016 21:36:36 +0000 (14:36 -0700)]
Fix wonky tail queue swap in condition variables code.

TAILQs happen to refer to themselves (double pointer), so just swapping the
contents of the struct is not enough.

Change-Id: Id06cdbda8dcc3f77812e943c4f8d38354cc2cb1f
Signed-off-by: Christopher Koch <chrisko@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix proc_is_dying() bug
Barret Rhoden [Wed, 3 Aug 2016 17:27:20 +0000 (10:27 -0700)]
Fix proc_is_dying() bug

Bug was added in f10bf40001fe ("Split PROC_DYING into DYING and
DYING_ABORT"), where I missed a "!".

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoVMM: Free VMCSs when appropriate
Barret Rhoden [Wed, 3 Aug 2016 17:16:03 +0000 (10:16 -0700)]
VMM: Free VMCSs when appropriate

Previously we weren't freeing them at all.  Additionally, if we failed
part of the way through a create_guest_pcore, we'd leak the VMCS we
allocated.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoVMM: Fix vmm_struct_init() off-by-one
Barret Rhoden [Wed, 3 Aug 2016 17:13:57 +0000 (10:13 -0700)]
VMM: Fix vmm_struct_init() off-by-one

We were returning and setting nr_guest_pcores to one less than the
number of cores we set up.

I also got rid of using 'i' outside the loop, which was slightly
confusing due to the other loop using its own 'i'.  I also cleaned up
some old comments that referred to the pre-waserror error handling
style.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoVMM: move to waserror/error style.
Ronald G. Minnich [Mon, 1 Aug 2016 22:29:23 +0000 (15:29 -0700)]
VMM: move to waserror/error style.

This simplifies the code and improves error diagnostics.

I've tested some of the error handling paths by trying to
set up a VM with bad parameters and also inserting some
calls to error() in a few places.

Change-Id: I5437f559f618c132be751897785aee6da3b771be
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoVMM: support use of waserror()/error() style.
Ronald G. Minnich [Thu, 21 Jul 2016 00:57:21 +0000 (17:57 -0700)]
VMM: support use of waserror()/error() style.

The vm startup is complicated and has lots of room for error.
In practice using the 'test return value' model has been
hard to use because the call order and functions are changing
-in the most recent case we're getting back
ENOMEM when the error is not ENOMEM at all.

Set up the sys_vmm_setup so that it can call functions
which use error(). I've talked to Barret and we're
good with this change.

Change-Id: I5260814cda2207eb8c698d5b8e9a27c5fb38fbf5
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
[ note that the retval is now -1 for failure.  this is fine.]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoUse PROC_DYING_ABORT for aborting syscalls
Barret Rhoden [Sun, 31 Jul 2016 20:47:59 +0000 (16:47 -0400)]
Use PROC_DYING_ABORT for aborting syscalls

The reason for all this is that some devices (#mnt) issue syscalls when
closing the FD, and those syscalls could block.  If we were DYING, those
syscalls would immediately abort.  #mnt didn't handle this well, and
went into an infinite loop.

The root of the problem is that we want the process to be dying, but we
don't want its syscalls to abort immediately.  We *do* want them to
abort at some point (I think).

We previously split the DYING state into DYING and DYING_ABORT.  All
code that cared about DYING also cared about DYING and DYING_ABORT.  Now
the actual abort code only checks DYING_ABORT, and not DYING.

One subtle change is that we close the FDT *after* aborting syscalls.
Previously we aborted syscalls first.  Devices should have no problem
with closes with outstanding syscalls - for instance, a close while
someone is blocked on an FD.  The user shouldn't do that, but they
could, so devices should be ready.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoSplit PROC_DYING into DYING and DYING_ABORT
Barret Rhoden [Sun, 31 Jul 2016 20:38:01 +0000 (16:38 -0400)]
Split PROC_DYING into DYING and DYING_ABORT

This commit just splits out the state into two different states, but
does not differentiate between them yet.  Everywhere that was checking
DYING before now checks DYING and DYING_ABORT equally.

We will need this split to deal with issues closing FDs when processes
are DYING.  In short, if the chan release methods attempt to block on a
rendez, the syscalls will abort immediately, since DYING is set.

We DYING_ABORT is a DYING state, but specifically one where we want all
syscalls to abort.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agox86: Don't backtrace from trampoline asm
Barret Rhoden [Thu, 28 Jul 2016 22:11:25 +0000 (18:11 -0400)]
x86: Don't backtrace from trampoline asm

Imagine this.  Userspace happens to load %rbp with a value that the kernel
cannot dereference.  Then it enters the kernel.  In the brief period before
the kernel sets rbp = 0 and starts its day, a profiling NMI arrives.  The
backtrace would flip out.

We could use something like a safe copy_from sort of call (copy_from_user()
won't work as is, incidentally, since it has built-in checks for user
addresses).  However, even if we set the address correctly, the user just
gained the ability to read kernel memory.  Set rbp, then do a bunch of null
syscalls in a loop with perf running.  Eventually you'll hit the bug.
Yeah, that's really rare.  Luckily, this did not come up - I just noticed
it in passing.

The nice thing about this approach is that the kernel should not be
backtracing beyond its entry point, regardless of the value of rbp.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agox86: Secure eflags when securing contexts
Barret Rhoden [Thu, 28 Jul 2016 20:42:21 +0000 (16:42 -0400)]
x86: Secure eflags when securing contexts

We had been making sure interrupts was on, but we weren't enforcing some of
the other flags.  I don't know if this is all of them, but it's the list of
ones that sounded dangerous from the SDM.

The IOPL one was probably a security hole.  A process could have asked the
kernel to pop a HWTF that had IOPL set to 3, and then started mucking with
devices.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agox86: Add protection from NMI contexts that trap
Barret Rhoden [Thu, 28 Jul 2016 19:29:38 +0000 (15:29 -0400)]
x86: Add protection from NMI contexts that trap

Remember the rules.  Among other things, NMI context code must be careful
when writing.  They can never grab locks.  These rules apply to faults
triggered by NMI context code.  This includes faults for things like
copy_from_user().

To limit the potential code of a faulting NMI's fault handler, I limited
the PF handler to just trying fixups.  The only code there is lock-free and
write-free.

To fix this up, I needed to clean up trap_dispatch a little.  Now we are
very explicit about what faults we handle (we had been handing T_GPF, which
wasn't on the list through the "default" handler).  Not a fan of that old
style.

I considered not adjusting the ktrap_depth during fault handlers from NMI
context.  The NMI could have interrupted another fault handler right when
it was in the read-modify-write process.  However, since the fault handler
returns the depth variable to its previous value, this interruption is
harmless.  I think.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoRemove backtraces from trace_printk()
Barret Rhoden [Wed, 27 Jul 2016 23:44:05 +0000 (19:44 -0400)]
Remove backtraces from trace_printk()

This reverts previous changes and restores trace_printk() to its
previous behavior: just printk into the trace log.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoRemove SEM_TRACE_BLOCKERS and TRACEME
Barret Rhoden [Wed, 27 Jul 2016 23:34:02 +0000 (19:34 -0400)]
Remove SEM_TRACE_BLOCKERS and TRACEME

Those are leftovers from the old op2 style tracing.  I noticed this
because trace_printk popped up in an NMI-enabled trace of block_test.
Gotta love the NMI sampling.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoClear excess parts of contexts when finalizing
Barret Rhoden [Wed, 27 Jul 2016 23:28:28 +0000 (19:28 -0400)]
Clear excess parts of contexts when finalizing

When we copy out the context from pcpui, we copy the entire struct
user_context.  However, when we fill the context, the amount we copy in
depends on the type.  Hypothetically, if a user has a smaller TF than
the previous resident, such as a SW TF running where a VM TF recently
existed, then the user could see some of the fields of the previous
resident.

By doing this during finalization, we limit the impact of the memset to
when we could give the context back to the user, i.e. after
finalization.

In the process, I moved the finalize routines from trap64.h to trap.c.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoperf: Use NMIs for sampling HW and VM TFs
Barret Rhoden [Wed, 27 Jul 2016 22:25:08 +0000 (18:25 -0400)]
perf: Use NMIs for sampling HW and VM TFs

Using NMIs allows us to sampling when interrupts are disabled.  It's
extremely useful.

To limit the amount of code we run from NMI context, we only record the
sample into a pre-allocated, per-cpu buffer.  Keep in mind the NMI rules
about writing and reading at the top of handle_nmi().

So NMIs record the backtrace, but don't emit the sample.  We self_ipi()
to trigger emitting the sample as soon as IRQs are reenabled.  If IRQs
were not disabled, this IRQ will hit as soon as the NMI returns.

vmexits for an NMI will also record the PC of the guest, but not attempt
a backtrace.  Previously, we were probably trying to backtrace.  Due to
the x86 NMI blocking issues, we don't attempt to do anything that might
fault from the vmexit NMI handler.

NMIs are now used for both perf monitoring and the monitor "trace
coretf".  The monitor's trace command is still a little dangerous.  This
commit also just moves all of that mess into monitor.c.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agox86: Prevent NMIs from nesting
Barret Rhoden [Tue, 19 Jul 2016 19:38:38 +0000 (15:38 -0400)]
x86: Prevent NMIs from nesting

If an NMI faults for any reason and then does an iret, the iret will clear
whatever protection hardware offers that prevents another NMI from nesting.
Basically, hardware will delay future NMIs until an iret.  The fault
handler's iret counts.

We get around this by having two stacks for NMIs.  One is for the real NMI
entry.  The second (the one in pcpui) is for the work done in NMI context.
This is the work that could get interrupted.  In that case, the NMI handler
makes sure the worker will do_nmi_work() again.

The main NMI handler and the bottom half work together such that a
concurrent NMI triggers a repeat of do_nmi_work().  The trickiness comes
when the bottom half tries to exit (by popping back to the original TF) and
an NMI happens at the same time.

The most error-prone and least-used part of this is how we handle that
scenario: the NMI handler notices the bottom half was trying to exit and
moves it to an alternate section of code that will return instead of
popping.  We can get away with this because there is a single instruction
that commits the "pop" of the TF and leaves the worker stack: iret.  It's
sort of like a restartable sequence, but instead of restarting, we undo the
operation.  That was relatively simple.  The harder part is writing the
nmi_try_to_pop, which is basically another NMI entry and exit under
slightly different circumstances.

I tested this a little.  I put a few direct jumps from within the OK case
to within the FAIL case.  I also put a "1: jmp 1b" loop in the OK case and
two nops in the FAIL case, added a breakpoint to do_nmi_work, and sent
another NMI to trigger the TF-hacking code.  Seems to work, for now.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agox86: Use a separate stack and handler for NMIs
Barret Rhoden [Mon, 25 Jul 2016 16:23:50 +0000 (12:23 -0400)]
x86: Use a separate stack and handler for NMIs

It turns out that on x86_64, you *must* use a separate stack for
NMIs.  On i386, this was an option.  Why, you ask?  Because SYSCALL (64
bit) differs from SYSENTER (32 bit) in that SYSCALL does *not* set the
stack pointer for the kernel on entry.  It's up to the SYSCALL/SYSENTER
entry point software to figure out and set the stack pointer.

The problem is that if you receive an NMI before the kernel can set the
stack pointer.  If your NMI handler doesn't use a separate, pre-determined
stack, the interrupt hardware pushes the basic interrupt info onto the
*current* stack, which happens to be a user-controlled pointer at this
point.  Good times.

For more fun times, we also need to return to user TFs directly, and not
call proc_restartcore().  See the notes on handle_nmi() for more info.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoJump stacks before unlocking semaphores
Barret Rhoden [Fri, 22 Jul 2016 19:07:17 +0000 (15:07 -0400)]
Jump stacks before unlocking semaphores

This popped up as a potential problem with NMIs, where a poorly timed
NMI could cause corruption.  It turns out that this was *a* problem, not
*the* problem.

As the comments note, this is only a problem for NMIs on architectures
that don't use the same stack.  x86_64 mostly requires a different stack
for NMIs (for other reasons), but other architectures might not have the
same requirements.  Better safe than sorry.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoClean up smp_idle's stack jumping
Barret Rhoden [Fri, 22 Jul 2016 18:41:55 +0000 (14:41 -0400)]
Clean up smp_idle's stack jumping

First off, RESET_STACKS is no longer an option.  There are weird cases
where you want to backtrace beyond smp_idle.  You can comment that out
manually if you want, but there's no need to make it a regular thing.
If you don't RESET_STACKS, you'll potentially run off the stack.

Other things:
- that disable_irq in smp_idle() wasn't really protecting anything.  No
  sense in doing it there.  We might need it to protect parts of the
KMSG subsystem, so I moved it to __smp_idle() for now.
- that cmb() did nothing.  The compiler won't reorder those asm
  operations.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoperf: Have arches handle the backtrace
Barret Rhoden [Tue, 19 Jul 2016 23:26:24 +0000 (19:26 -0400)]
perf: Have arches handle the backtrace

Instead of having arch-independent perf do the backtraces, let the arch
generate the BT and pass it to the arch-independent part.

This will matter for NMI tracing, where the actual pc_list will be saved
somewhere temporarily and then emitted.  Only x86 needs to know about that.

This also removes the add_trace() option.  It's a bad thing to do.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agox86: Upgrade backtrace
Barret Rhoden [Tue, 19 Jul 2016 23:02:23 +0000 (19:02 -0400)]
x86: Upgrade backtrace

Previously, we would report zero PCs if the FP was 0.  Now we'll at least
report the PC we were given.

Now that we're using two different functions for the kernel and user, we
can be more careful in the kernel's function when backtracing.

Finally, this is more clear with regards to the end conditions for the
loop.

But wait, you say, isn't that fp check in the kernel's BT unnecessarily
slow?  fp < KERNBASE, so we don't need to write the far more
understandable:

if (!fp || fp < KERNBASE)
break;

and we can write this instead!

if (fp < KERNBASE)
break;

Those generate the same code.  Don't be too clever, the compiler might
outsmart you.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoperf: Only record PC once
Barret Rhoden [Tue, 19 Jul 2016 21:58:27 +0000 (17:58 -0400)]
perf: Only record PC once

This was recording PC in the backtrace, then PC would be included a second
time.  I don't know if that was having any adverse affects on perf, or if
it was just making me wonder what the heck was going on.

Btw, I see that it was trying to cover for cases where FP was 0
immediately.  It's best to let the helper functions do that.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoChange vmrunkernel to use getopt()
Kyle Milka [Fri, 22 Jul 2016 16:09:53 +0000 (09:09 -0700)]
Change vmrunkernel to use getopt()

Change-Id: I38c9fd56b346ccd2cff713f0cd9c929d5550d9c3
Signed-off-by: Kyle Milka <kmilka@google.com>
[changed an extra 'c' to 's' in getopt]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoGet command line options from a file
Kyle Milka [Fri, 22 Jul 2016 16:09:52 +0000 (09:09 -0700)]
Get command line options from a file

We can now use the -k command line option to specify a file from which
to get the command line arguments. Now vmrunkernel doesn't need to be
modified every time you try to run a different kernel.

Change-Id: Ib4e60dbb03e0040cd2268234e080ba302cdc9ce3
Signed-off-by: Kyle Milka <kmilka@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoImplemented virtio-block
Kyle Milka [Fri, 22 Jul 2016 16:09:51 +0000 (09:09 -0700)]
Implemented virtio-block

We were able to get various Linux kernels to mount a disk image. Used
linux/lguest.c and virtio_net.c as starting points. This included adding
the block device struct and request and init functions.

Change-Id: I91a603d5a6e9c27c87a29d0784de6fe17cc94916
Signed-off-by: Kyle Milka <kmilka@google.com>
Signed-off-by: Gan Shun Lim <ganshun@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoProperly limit glibc's alloca() (XCC)
Barret Rhoden [Tue, 19 Jul 2016 22:39:35 +0000 (18:39 -0400)]
Properly limit glibc's alloca() (XCC)

The old sysdep wasn't even called.  We'd need nptl to be a feature to get
that sysdep added, I think.

Instead, we'll have to change something outside the sysdeps folder:
alloca.h.

Glibc at least checks that alloca is okay before using it.  I don't think
these same sanity checks go into uses of alloca() by regular programs, so
this may pop up again in the future.

Fixes: df1135d0583e ("Specify a small alloca_cutoff (XCC)")

Rebuild glibc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoUpdate version-controlled scripts for bash
Barret Rhoden [Fri, 15 Jul 2016 23:12:29 +0000 (19:12 -0400)]
Update version-controlled scripts for bash

Due to a bug in bash/wait/Akaros, the number-of-arguments checking doesn't
work for many of the scripts.  It works the first time the script is run
per bash instance.  This patch will allow us to work until the bug is
found.

Check your own, non-version-controlled scripts.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdd a gitignore to bash
Barret Rhoden [Fri, 15 Jul 2016 23:01:57 +0000 (19:01 -0400)]
Add a gitignore to bash

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoStore debug info for likely blocking syscalls
Barret Rhoden [Fri, 15 Jul 2016 20:07:26 +0000 (16:07 -0400)]
Store debug info for likely blocking syscalls

These calls block all the time and weren't easily visible in "db sem".

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAllow site-specific mountroot hosts
Barret Rhoden [Fri, 15 Jul 2016 19:55:04 +0000 (15:55 -0400)]
Allow site-specific mountroot hosts

Similar to how ifconfig works, you can specify your own hosts that aren't
in a version-controlled KFS file.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdapt devalarm to the new unset_alarm [2/2]
Barret Rhoden [Fri, 15 Jul 2016 19:35:05 +0000 (15:35 -0400)]
Adapt devalarm to the new unset_alarm [2/2]

Devalarm was trying, and failing, to handle the old style of unset_alarm().
Specifically, in its kref release, it was freeing the memory after an
unset.  The unset would succeed, but the RKM was still pending.  I had this
happen; it was fun.

This also fixes a minor bug with firing FD taps outside the lock.  At
least it looked wrong.

All in all, I'm not super happy with the sync in use here.  Here's the
issue.  We need to sync between unset and set.  unset blocks, so we need
some sleeping sync.  We also need some sync between the handler and other
operations (e.g. on 'count' and the timerfd wakeup).  Since unset waits-on
the handler, we can't use the same sync for "unset-to-set" and
"handler-to-others".  Finally, we need something for the timerfd that
allows aborts, such as the CV (or maybe a hacked rendez, but that is just a
CV under the hood).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix issues with unset_alarm() [1/2]
Barret Rhoden [Fri, 15 Jul 2016 19:30:55 +0000 (15:30 -0400)]
Fix issues with unset_alarm() [1/2]

Previously, unset_alarm() would return before an RKM alarm would fire.  It
was up to users (e.g. devalarm) to deal with it.  That's a real pain.

Now, unset_alarm() will block until we're sure the alarm is done.  This
gets tricky for alarms that rearm themselves.

As a side-effect of this, unset_alarm() now has a waits-on dependency on
the handler for RKM alarms.  (All of this is much simpler with IRQ alarms).

In the process, I cleaned up the reset_* family, which were just unset/set
helpers.

Odds are, there are more problems with this that will pop up later.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoRemove the alarm-with-no-func use case
Barret Rhoden [Thu, 14 Jul 2016 14:54:04 +0000 (10:54 -0400)]
Remove the alarm-with-no-func use case

The old version allowed you to just block on a semaphore if you passed '0'
for the function.  No one was using it, and it complicated the
implementation.  Its functionality has been superceded by functions like
kthread_usleep().

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoUse an IRQ alarm in rendez_sleep_timeout()
Barret Rhoden [Thu, 14 Jul 2016 14:04:18 +0000 (10:04 -0400)]
Use an IRQ alarm in rendez_sleep_timeout()

Using an RKM alarm in this way is buggy.  Consider the case where the alarm
immediately fires, and we don't sleep.  "Fires", currently means the alarm
IRQ happened, not that the function ran!  Yikes.  So the RKM gets sent to
our core to run in the future.  Then we don't block (the rendez condition
happened or saw we weren't on the tchain), and we return.  Since we return,
we unwind the stack and basically free the alarm structure.  Later, the RKM
accesses this freed memory.  Based on some code comments, I was aware of
this possibility, but missed it when making rendez_sleep_timeout().

The real problem is unset_alarm() doesn't actually guarantee that the
memory is unused.  It should, which is the subject of a future patch.
However, it will basically require unset_alarm for RKM alarms to
potentially block, which we'd like to avoid in rendez code.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdd support for better backtraces
Barret Rhoden [Wed, 13 Jul 2016 16:46:02 +0000 (12:46 -0400)]
Add support for better backtraces

At the cost of performance.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agox86: Ensure boot_pgdir's user entries are unmapped
Barret Rhoden [Tue, 12 Jul 2016 18:30:39 +0000 (14:30 -0400)]
x86: Ensure boot_pgdir's user entries are unmapped

For sanity reasons, we should never have anything in boot_pgdir below ULIM.
Technically, we could make it work, but not without some thought.  The
issues is that PML4 entries are pointers, pointing to common PML3s.  Any
entry in boot_pgdir is shared with every process, from the PML3 on down.
The kernel expects to manage and synchronize global access to the kernel
mappings (above ULIM).  But memory below ULIM is managed per-process.

Backstory: I was trying to debug a null function pointer by mapping
something at page 0.  The kernel panicked after decreffing a page too many
times.

What happened was that inserting one page at virtual addr 0 created a PML3,
PML2, and PML1 that was shared between every process - not just the page
mapped at 0.  This PTE reach was 512 GB, including the program binary
(which was in the page cache).

The first process was fine.  However, when we forked, the pages for e.g.
busybox's text segment already had PTEs in the new process's address space.
Technically, they were the same PTEs (and PML3, 2, and 1) as the parent
process, since they were shared data structures.

Anyway, map_page_at_addr() saw that the PTE had a mapping, so it decreffed
the page before inserting a new page.  It just so happened that the new
page was the same as the old one, since it was a fork (duplicate_vmrs,
etc).  That page had a single refcnt, since it was managed by the page
cache, causing it to be freed.

Now the page is freed, but it is in the page tables still, since
map_page_at_addr() wrote the PTE with the value of the page.  Basically, it
was a "replace the PTE with its own value", but it triggered a decref.

Next up was the VMR for busybox's MAP_PRIVATE vmr.  Since it's a private
mapping, it gets its own page.  upage_alloc() gives us the most recently
freed page, which was the one that was still in the address space, right at
the top of the text segment.

Eventually the process page faults, probably because of the madness of its
address space.  When it does, the kernel puts every page in the VMRs.  At
least one page (the one we discussed) was in there twice.  The second
decref triggers the kref assert, since we decreffed something that was
already 0.

Good times.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoDon't decref page map pages
Barret Rhoden [Tue, 12 Jul 2016 18:33:29 +0000 (14:33 -0400)]
Don't decref page map pages

I triggered this due to another bug.  Basically, map_page_at_addr()'s two
error-cases assumed the page was not in the page map.  Those pages
shouldn't be decreffed; the page map manages their refcnt.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdd a helper for detecting page map pages
Barret Rhoden [Tue, 12 Jul 2016 18:12:25 +0000 (14:12 -0400)]
Add a helper for detecting page map pages

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdd sanity checks to __prep_signal_handler()
Barret Rhoden [Mon, 11 Jul 2016 19:53:45 +0000 (15:53 -0400)]
Add sanity checks to __prep_signal_handler()

If a uthread messed up its stack pointer and then segfaulted, the uthread
code would crash nastily when we attempted to inject the SIGSEGV.  This
sanity check will catch common problems in this area.

For instance, put this in pthread_test:

asm volatile ("mov $0, %rsp; push %rax");

Ultimately, using the uthread's stack in this manner is a bit dangerous.

This is especially true since  __prep_signal_handler() basically does an
alloca for the context and ancillary state.  So any 2LS that uses signals
needs a suitable large uthread stack.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoSpecify a small alloca_cutoff (XCC)
Barret Rhoden [Mon, 11 Jul 2016 19:43:22 +0000 (15:43 -0400)]
Specify a small alloca_cutoff (XCC)

Glibc uses this function to determine if it can do an alloca.  Given that
we don't know what 2LS thread we're in, or even if we're in vcore context,
we don't know much about the stack size of the caller.

I'm flexible on changing the size, given that the smallest stack we'll
probably deal with is PGSIZE.

Rebuild glibc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoparlib/x86/atomic.h: (void) __sync_fetch_and_* calls
Ronald G. Minnich [Mon, 18 Jul 2016 17:39:02 +0000 (10:39 -0700)]
parlib/x86/atomic.h: (void) __sync_fetch_and_* calls

In several cases the return from __sync_fetch_and_* is ignored
and external builds were throwing errors when -Werror was used.

Indicate via the standard (void) cast that the
return from the call can be ignored.

Change-Id: I944cbaf25f5e7ecadf01d206fcc0c74935183780
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoBASH for Akaros.
Dan Cross [Fri, 15 Jul 2016 22:00:54 +0000 (18:00 -0400)]
BASH for Akaros.

This is a Makefile, a patch, and a line in the top-level
Makefile bringing in BASH for Akaros.  I've been using this
as my shell for a few months now.

Change-Id: I09032cf55dc596f04cdc4ed4f741c9bddd2d78a2
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoRemove '-rR' from MAKEFLAGS in tools/Makefrag.
Dan Cross [Tue, 12 Jul 2016 20:43:54 +0000 (16:43 -0400)]
Remove '-rR' from MAKEFLAGS in tools/Makefrag.

Among possibly other things, we cannot build 'bash' with this
set.  However, we do NOT remove this from the top-level Makefile
to avoid mucking about with the kconfig environment too much.

Change-Id: I35be1556c5b535c040824973e53a9a08727e069f
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoInvoke shells from the kernel by name/path.
Dan Cross [Tue, 12 Jul 2016 21:29:54 +0000 (17:29 -0400)]
Invoke shells from the kernel by name/path.

Don't use the 'busybox' binary as a trampoline to start a shell.
Instead, invoke the shell directly using a filesystem name for
the shell binary: /bin/bash.  Also, rename the monitor function
to invoke a shell from, "mon_bb" to "mon_shell".  Add monitor
commands 'bash' and 'sh' to invoke the shell as, '/bin/bash'.

Tested: Built and ran Akaros.

Change-Id: I56be992292b28762c9925b9b40f2d765ca1e1313
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFixed 32bit error in lseek
Kyle Milka [Fri, 15 Jul 2016 20:30:56 +0000 (13:30 -0700)]
Fixed 32bit error in lseek

Lseek truncated the result when offset was a 64bit value.

Change-Id: I222afb0b5570a2dfac7a002593baaae322f9024a
Signed-off-by: Kyle Milka <kmilka@google.com>
[removed virtio-blk extras]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix refcnting bug in DTLS
Barret Rhoden [Fri, 8 Jul 2016 20:25:00 +0000 (16:25 -0400)]
Fix refcnting bug in DTLS

I think this is right.  It's odd to up the refcnt on every set_dtls.  We're
just setting the value.  IIUC, the refcnt is meant to keep key alive since
we're storing a ref to it in V.

This bug was probably harmless - just some wasted memory.  You'd need 4
billion set_dtls calls followed by a poorly timed decref to cause serious
trouble.  =)

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoInitialize all vcores in SCP mode
Barret Rhoden [Wed, 6 Jul 2016 17:56:20 +0000 (13:56 -0400)]
Initialize all vcores in SCP mode

Previously, we were initializing vcores on demand.  Now we'll just take
care of them early, before anything crazy goes on.  We still wait until we
know the user wants an MCP before prepping vcores > 0.  The newer style is
a little simpler and a little safer.

The old style could be troublesome since allocating TLS results in a
malloc.  Then we'd be mallocing from any context that could request vcores
- including vcore context.  (e.g. a 2LS wants more vcores in sched_entry).

In general, malloc from vcore context is getting to be a little dangerous,
due to the various locks that could be held by a uthread.  Say a uthread
grabs a malloc lock, but it is preempted.  Then vcore context tries to
malloc, resulting in a deadlock.

One solution is to fix up glibc to use PDR locks - that scenario is what
they are designed for.  There are a couple issues with that for now, and
simply reducing the amount of code that is called from vcore context is
always a good thing.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoImplement poll() on top of select()
Barret Rhoden [Fri, 1 Jul 2016 20:21:08 +0000 (16:21 -0400)]
Implement poll() on top of select()

It's hokey in the same ways that select() is, and a few more on top of
that.  Gotta love the layers.

I considered switching things around and implementing select() on top of
poll(), but it's probably not worth the hassle, especially since it's all
nasty hacks.  Plus our main consumers use select(), not poll, and I'd
rather have less layers to debug.  Incidentally, I should have implemented
select() with pselect().

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoMove vfprintf.c out from sysdeps (XCC)
Barret Rhoden [Wed, 6 Jul 2016 22:47:02 +0000 (18:47 -0400)]
Move vfprintf.c out from sysdeps (XCC)

While debugging, I noticed that sysdeps/akaros/vfprintf.c isn't always
used.  Both sysdeps/akaros/vfprintf.c *and* stdio-common/vfprintf.c are
compiled.  This is because some of the other printf C files in stdio-common
 #include vfprintf.c directly, and those get the old version.

Keeping two versions will lead to even more insanity, so we'll just modify
the non-sysdep version.

Rebuild glibc and cross your fingers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoUse mmap(), not malloc(), in vfprintf (XCC)
Barret Rhoden [Fri, 1 Jul 2016 18:51:18 +0000 (14:51 -0400)]
Use mmap(), not malloc(), in vfprintf (XCC)

Using malloc created an ordering between any of the printf calls and
malloc.  If malloc itself did anything that called back into printf, such
as a diagnostic warning, a SIGSEGV (which leads to printing), an snprintf
to talk to a kernel device, etc, then malloc would be calling itself.  That
could trigger a deadlock, depending on what malloc does internally.

By relying on mmap() only, we limit the amount of code that printf depends
on.  Note that if you ever put a printf in glibc's mmap() stub, you might
have issues.  Imagine a generic printf call: grabs glibc's IO lock, mmaps,
tries to print, then deadlocks on the *IO lock*.

Rebuild glibc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFix lock ordering with CONFIG_SEMAPHORE_DEBUG
Barret Rhoden [Wed, 6 Jul 2016 20:42:18 +0000 (16:42 -0400)]
Fix lock ordering with CONFIG_SEMAPHORE_DEBUG

This has been broken forever.  If a kthread was sleeping at the same time
as we did a "db sem", then we could deadlock.  print_all_sem_info() would
grab the list lock, then each sem lock.  The sleepers would grab their own
lock, then the list lock.

This fixes the ordering problem, but at the expense of greater overhead on
every semaphore sleep operation.  If you care about perf, you probably
shouldn't be running with SEMAPHORE_DEBUG anyways, though I always do.

For those curious, here's how I found this brutal bug.  I had an app that
was WAITING.  I did a db sem, and Core 0 locked up.  I repeated it in qemu,
and saw other cores were locked up and where.  Core 0 was in
print_sem_info.  The others were in debug_downed_sem.  The interesting bit
was that the app was making short, blocking calls very quickly - enough so
that the process was WAITING whenever I looked, but blocks would happen
frequently on the timescale of a printk (msec).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoRemoved more patches to linux
Kyle Milka [Fri, 1 Jul 2016 16:19:35 +0000 (09:19 -0700)]
Removed more patches to linux

Sets up the EBDA and adds a command line option that allows
us to run the master branch of Linux.

Change-Id: Ib9af5c3bbdf120ca6264966fc4ad39d2c3f68aa8
Signed-off-by: Kyle Milka <kmilka@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoGive the guest more memory.
Kyle Milka [Fri, 1 Jul 2016 16:19:34 +0000 (09:19 -0700)]
Give the guest more memory.

Increase memory to 1 GB instead of 128 MB. Also change KERNSIZE.

Change-Id: Iaa8e3a7922bf1f4ade6789f9bce07427d3e80eb8
Signed-off-by: Kyle Milka <kmilka@google.com>
[spaces around operators]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoFixed ISOR problem and legacy pic patch.
Kyle Milka [Fri, 1 Jul 2016 16:19:33 +0000 (09:19 -0700)]
Fixed ISOR problem and legacy pic patch.

After removing Ron's null_legacy_pic patch from linux it is possible
to use the IOApic in the way it was intended, without resorting to the
ISOR table. IRQs are now assigned sequentially starting at 0.

Change-Id: I7f252105f0a2dfd4296648c18bc80332d048be0b
Signed-off-by: Kyle Milka <kmilka@google.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agoAdded virtio network device.
Kyle Milka [Fri, 1 Jul 2016 16:19:32 +0000 (09:19 -0700)]
Added virtio network device.

We were able to get Linux to send a ping through the virtio device. Used
linux/lguest.c as a starting point and virtio_lguest_console.c for finding
the names of our version of the functions. This included adding the
network device struct and transmit and receive functions.

Fixes: b/29178446
Change-Id: I840c0acc617d238fb2b24b5662ee76f615bc743f
Signed-off-by: Kyle Milka <kmilka@google.com>
[checkpatch touchups, moved write() outside assert()]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agox86: Allow getting/setting p/c-states via devarch
Barret Rhoden [Thu, 30 Jun 2016 21:02:17 +0000 (17:02 -0400)]
x86: Allow getting/setting p/c-states via devarch

We don't offer any support here.  The user needs to know by other means
what values to set, such as by reading MSR_TURBO_LIMIT, Intel docs, etc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
3 years agox86: Use P-states and C-states (XCC)
Barret Rhoden [Thu, 30 Jun 2016 19:20:22 +0000 (15:20 -0400)]
x86: Use P-states and C-states (XCC)

To use turbo mode, we need to both set the fastest P-state, which is the
turbo mode ratio, and have the halted cores enter a deep enough C-state to
allow the hardware to boost the 'active' cores.  To halt in any C-state
deeper than C1, you need to use mwait.

For those curious, you can see the max ratio available, given the number of
active cores, in MSR_TURBO_RATIO_LIMIT.  For instance, on my Haswell, I get
something like:

/ $ rdmsr 0x1ad
Core   0, MSR 0x000001ad: 0x1a1a1b1c1d1e2020

That means that if you have 0-1 cores active, they can each get to 0x20.
Two cores, 0x1e.  Etc.  If all cores are active, it's 0x1a.  (There are
other MSRs for the additional cores, but they are all 0x1a).

Those ratios are multiplied by the bus freq, 100 MHz in this case.  So this
means the top-end for Turbo mode is 3.2 GHz.  If all the cores are running,
each core maxes out at 2.6 GHz.  The default at boot is 0x18, which is
2.4 GHz, and also happens to be the (invariant) TSC frequency.

This commit adds a very basic infrastructure for managing P-states and
C-states, and it uses mwait to halt when available.

By default, every core will be set to the fastest P-state and the
shallowest sleep that still allows Turbo mode.  I think.

I'll provide an interface via devarch for users to tweak this however
they'd like.  As future work, we can add something like Linux's idle driver
and/or acpi-cpufreq driver.  Or we can just leave it to userspace.

Reinstall your kernel headers.

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