4 years agox86: Fix cpu detection shift error
Barret Rhoden [Thu, 30 Jun 2016 18:24:54 +0000 (14:24 -0400)]
x86: Fix cpu detection shift error

That's an ancient bug, from back when this code was in kern/init.c (not
kern/src/init.c either!).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoAdd a readnum() variant for hex
Barret Rhoden [Thu, 30 Jun 2016 20:59:12 +0000 (16:59 -0400)]
Add a readnum() variant for hex

Yet another read.* helper for read() on various devices.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoVMM: Sync halting GPCs and interrupt injection
Barret Rhoden [Mon, 20 Jun 2016 20:48:57 +0000 (16:48 -0400)]
VMM: Sync halting GPCs and interrupt injection

Previously, halts and mwaits were just immediately returning.  This led to
the guest spinning while waiting on console I/O.  You could see this if you
ran 'ps' while the VM was running.

Now when we send interrupts, we synchronize with the halting guest thread,
such that the guest can halt until it receives an IRQ.  Everyone who wants
to send an IRQ (vector!) to a guest pcore must use vmm_interrupt_guest().

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoVMM: Add the GUEST_INTR_STATUS to the VM TF (XCC)
Barret Rhoden [Tue, 21 Jun 2016 16:50:08 +0000 (12:50 -0400)]

We need this to halt properly.  I squeezed the u16 into the existing
padding both to save space as well as to keep people from needing to do
full rebuilds.

Reinstall your kernel headers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoVMM: Touch up ros/vmx.h's includes (XCC)
Barret Rhoden [Mon, 20 Jun 2016 20:38:44 +0000 (16:38 -0400)]
VMM: Touch up ros/vmx.h's includes (XCC)

We need those includes to compile.  I ran into this while making a new C

We also need to get rid of the rdmsr macros, since userspace should never
even call that.  Right now, you could get a compilation error with those
macros since read_msr() isn't in any user headers.

Reinstall your kernel headers

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoVMM: Exit on mwait
Barret Rhoden [Mon, 20 Jun 2016 20:36:11 +0000 (16:36 -0400)]
VMM: Exit on mwait

Mwait can be used for power management.  Linux will use mwait instead of
halt in some circumstances.  See Linux's arch/x86/kernel/process.c
prefer_mwait_c1_over_halt() for more info.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Fix stat's stdout on the console
Barret Rhoden [Thu, 23 Jun 2016 14:49:43 +0000 (10:49 -0400)]
perf: Fix stat's stdout on the console

The old version worked if you ssh'd in, but not if we were directly on
the console.  Actually, I shouldn't have bothered with fdopen() in the
first place.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Fix the top-level Makefile
Barret Rhoden [Thu, 23 Jun 2016 01:03:36 +0000 (21:03 -0400)]
perf: Fix the top-level Makefile

I missed this during the perf rename in commit ddb10ee574a3 ("perf: Move
to dev-utils/perf")

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoHave checkpatch ignore Gerrit change-ids
Barret Rhoden [Mon, 20 Jun 2016 17:37:02 +0000 (13:37 -0400)]
Have checkpatch ignore Gerrit change-ids

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoUpdate rules for contributing external code
Barret Rhoden [Mon, 20 Jun 2016 17:33:19 +0000 (13:33 -0400)]
Update rules for contributing external code

We can merge the spatch and reformatting steps into one commit.  Those
steps (and their fixups) are just part of an "automated conversion" commit.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoRename event_bits.h -> bits/event.h (XCC)
Barret Rhoden [Mon, 20 Jun 2016 15:04:12 +0000 (11:04 -0400)]
Rename event_bits.h -> bits/event.h (XCC)

Reinstall your kernel headers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoGracefully fail ipconfig when DHCP times out
Barret Rhoden [Mon, 20 Jun 2016 14:57:56 +0000 (10:57 -0400)]
Gracefully fail ipconfig when DHCP times out

For aborted syscalls, the errstr is "syscall aborted".

We don't need the 30 retries loop, since dhcpquery() already tries multiple
times internally (10 seconds worth of retries).  The way it was, you'd wait
for about 5 minutes if DHCP failed.

All stderr printfs ought to have a trailing \n, so we can see the output
more easily.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoUpdate scripts/git/mbox-to-patches.sh
Barret Rhoden [Fri, 17 Jun 2016 18:22:12 +0000 (14:22 -0400)]
Update scripts/git/mbox-to-patches.sh

It's simpler, lets git do more of the heavy lifting, and handles different
content transfer encodings.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoVMM: Dynamically retrieve the interrupt vector for a virtio device.
Kyle Milka [Fri, 17 Jun 2016 15:57:35 +0000 (08:57 -0700)]
VMM: Dynamically retrieve the interrupt vector for a virtio device.

We dynamically get the interrupt vector from ioapic_write to the
relevant irq in virtio_console. The poke_guest function now posts
the interrupt vector for a specific device.

We now no longer need Ron's vroom patch for linux.

Fixes: b/29243001
Change-Id: I222f33582c013dc730412d28881a184d0ae31fb1
Signed-off-by: Kyle Milka <kmilka@google.com>
[ masked 'value' in DPRINTF ]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoACPI: Allow multiple SRATs
Barret Rhoden [Fri, 17 Jun 2016 16:16:39 +0000 (12:16 -0400)]
ACPI: Allow multiple SRATs

Once we start using the SRATs for something, we'll need to parse the extra

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Update documentation
Barret Rhoden [Wed, 15 Jun 2016 20:41:33 +0000 (16:41 -0400)]
perf: Update documentation

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Move to dev-utils/perf
Barret Rhoden [Thu, 16 Jun 2016 21:41:23 +0000 (17:41 -0400)]
perf: Move to dev-utils/perf

For lack of a better naming system, we'll use Gentoo's.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Report maximum values for counter overflow
Barret Rhoden [Thu, 16 Jun 2016 19:34:45 +0000 (15:34 -0400)]
perf: Report maximum values for counter overflow

The counters can overflow and wrap around.  Previously, if that happened,
we'd just report the wrapped value.  Now we'll report the maximum value.
Userspace (perf stat) can handle that if we'd like to.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Track PIDs for kernel samples (XCC)
Barret Rhoden [Thu, 16 Jun 2016 18:19:14 +0000 (14:19 -0400)]
perf: Track PIDs for kernel samples (XCC)

When the kernel is running on behalf of the user, we'd like to attribute
those samples to that process.  We now report that info.

Incidentally, I dabbled with reporting the vcoreid for user samples as the
TID.  That won't work, since TID is more of a PID on Linux.

Reinstall your kernel headers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoRemove kprof's timer (XCC)
Barret Rhoden [Thu, 16 Jun 2016 17:32:40 +0000 (13:32 -0400)]
Remove kprof's timer (XCC)

The timer functionality doesn't work with the new perf, and it actually
hasn't worked since the removal of kprof2perf back in commit 8c9e8985be92
("Move Linux perf format conversion into perf tool, drop kprof2perf").

If we ever need this functionality back, we can add it in and make it part
of perf properly.  The timer can be a sort of OS event (software vs
hardware), which the kernel can count and generate samples.

We don't need the PROF_ stuff either.  When the kernel generates the event,
it'll pass back a u64 (e.g. user_data in the existing PMU code) that the
user can tie to a specific perf_event.

Reinstall your kernel headers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoRemove op2.go
Barret Rhoden [Thu, 16 Jun 2016 15:42:37 +0000 (11:42 -0400)]
Remove op2.go

The kernel no longer exports the format that op2 was converting.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoHandle lack of chaninfo() in print_chaninfo()
Barret Rhoden [Wed, 15 Jun 2016 20:38:45 +0000 (16:38 -0400)]
Handle lack of chaninfo() in print_chaninfo()

The output was a bit ugly and probably not what we wanted.  This is what
you see when you do a 'pip' from the monitor.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Use PERF_SAMPLE_IDENTIFIER
Barret Rhoden [Wed, 15 Jun 2016 20:30:31 +0000 (16:30 -0400)]

Instead of PERF_SAMPLE_ID.  It's the preferred way to ID an event, and both
older and newer perfs can handle it.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Remove unused CMD_COUNTER_STATUS bits (XCC)
Barret Rhoden [Wed, 15 Jun 2016 20:06:29 +0000 (16:06 -0400)]
perf: Remove unused CMD_COUNTER_STATUS bits (XCC)

The kernel was just returning zeros for these values.  They aren't
particularly useful either, since the user already knows them.

While I was fixing the kernel, I also removed an unneccessary intermediate

Reinstall your kernel headers for the documentation change.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Don't output counters for perf record
Barret Rhoden [Wed, 15 Jun 2016 19:54:53 +0000 (15:54 -0400)]
perf: Don't output counters for perf record

The value of the PMU counters is meaningless.  For perf record, we care
about overflow samples, not about the raw count.  Now that we have perf
stat, we don't need this functionality at all.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Output Version 0 perf_event_attrs
Barret Rhoden [Wed, 15 Jun 2016 19:46:45 +0000 (15:46 -0400)]
perf: Output Version 0 perf_event_attrs

We aren't using the extra stuff from versions 1 and beyond.  Some older
versions of perfs on Linux seem to have trouble with the newer format.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Remove the kprof.pdata staging ground
Barret Rhoden [Wed, 15 Jun 2016 18:25:19 +0000 (14:25 -0400)]
perf: Remove the kprof.pdata staging ground

Previously, kpdata would be a snapshotted view of the profiler queue.  This
was a pain, and it didn't help with anything.  Instead, now we just drain
the profiler queue directly.

This is also a nice step towards having multiple profilers, instead of the
existing global profiler.  When you open kpctl, the chan has a reference on
a profiler.  That happens to be the global one now.  When you close the
chan, the profiler is released.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Delay the opening of kpctl
Barret Rhoden [Wed, 15 Jun 2016 15:29:52 +0000 (11:29 -0400)]
perf: Delay the opening of kpctl

Only perf record needs it, and since kpctl only allows one opener at a
time, this prevents multiple perf commands.  We still can only run one perf
record at a time (due to the global profiler), but now we can run something

perf record -e cycles perf stat -e bus-cycles hello

Where perf record tracks perf stat tracking hello.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Use stat instead of seeks for xfsize
Barret Rhoden [Wed, 15 Jun 2016 18:22:39 +0000 (14:22 -0400)]
perf: Use stat instead of seeks for xfsize

It's faster and doesn't rely on a file being seekable.  I don't know how
well seeks work with qio queues...

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Add the perf stat subcommand
Barret Rhoden [Wed, 15 Jun 2016 16:05:28 +0000 (12:05 -0400)]
perf: Add the perf stat subcommand

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Minimize the sampling of perf itself
Barret Rhoden [Wed, 15 Jun 2016 15:10:30 +0000 (11:10 -0400)]
perf: Minimize the sampling of perf itself

The perf events fire as soon as you submit them to the kernel.  We can
control whether or not we gather the actual samples (i.e. backtraces) for
perf record.  This will minimize the impact of perf on the trace, as well
as just be a little cleaner.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Shutdown profiler/sampling on kpctl close
Barret Rhoden [Tue, 14 Jun 2016 20:48:57 +0000 (16:48 -0400)]
perf: Shutdown profiler/sampling on kpctl close

There are two options for stopping the profiler: manually with a stop
command or by closing the FD.  We now support both.

The issue is a generic one that affects all of the Plan 9 devices, and the
root of the problem is how to deal with errors.  Let's use kprof as an

Previously, to stop the profiler, you'd need to `echo stop > kpctl`.  This
works fine, so long as some program actually does this.  If for some reason
your program dies, e.g. perf crashes or exits with an error, it does not
stop the profiler.

If you do `perf record sleep 10 &; kill $PERF-PID`, then the profiler will
keep running.  (Side note: devarch's 'perf' file shuts down on close, so
we're only collecting mmap and comm events).  We're stuck waiting on an
event that will never occur.

The way to deal with this is to shutdown when the FD is closed.  This works
because the FD is implicitly closed when the process exits for any reason.
This also could work in a distributed system - eventually we can time out a
mount RPC and shut things down.  So by tying teardown into closing the FD,
we get fault tolerance with one mechanism.

The downside to using a close() as the signal to shutdown is you can no
longer easily control the device from the shell.  If you 'echo start >
kpctl`, it will start and then immediately stop when `echo` exits and its
FDs are closed.  That is the tradeoff.

This is not a new tradeoff in Plan 9.  The same thing happens with the IP
stack.  If you `cat /net/tcp/clone`, you'll create the conversation, but
the conversation closes as soon as `cat` exits.  I think the netlogger has
a similar issue (need to keep it open for logging to work).  Basically,
devices vary!

Ultimately, the power and value of the text based interface to these
devices isn't actually that it is scriptable, but that it is machine
independent.  Scripting is a nice convenience.

Oh, I kept the "stop" command around so that we can stop and start the
profiling without having to close the FD.  You want close() to work as an
option/failsafe, not as the only way to stop the device.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Fix race in arch_perf_write()
Barret Rhoden [Tue, 14 Jun 2016 19:58:49 +0000 (15:58 -0400)]
perf: Fix race in arch_perf_write()

We could have concurrent readers and writers.  If a writer came in at the
same time as a reader or another writer, they'd race on the response

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Report errors when counter setup fails
Barret Rhoden [Tue, 14 Jun 2016 19:40:18 +0000 (15:40 -0400)]
perf: Report errors when counter setup fails

Previously, the kernel would return a negative value for PED, but perf
would ignore it.  Then later we'd try to close it and would get a cryptic
value back (negative value out of range).

Now we try to provide helpful errstrs.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Remove the kref from perfmon_session
Barret Rhoden [Tue, 14 Jun 2016 19:16:14 +0000 (15:16 -0400)]
perf: Remove the kref from perfmon_session

The sessions are 1:1 with perfmon_contexts.  The context in devarch is the
way in which to access the session, so we don't need to do any reference
counting.  Note that perfmon_get_session() was never called - we had no use
for it.

Likewise, arch_free_perf_context() should never be called with 0.  The one
time it is called, the caller checks.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Clean up perf_{session,alloc} management
Barret Rhoden [Tue, 14 Jun 2016 17:59:27 +0000 (13:59 -0400)]
perf: Clean up perf_{session,alloc} management

The big thing was the unnecessary kref on the alloc.  Due to that, we had
the weird alloc_get helper, which either got a ref or dropped it.  We don't
need any of that, and it confuses things.

The one important thing is to use a qlock to avoid a deadlock.  Deadlock is
the likely reason for the kref in the first place, but it was just

I cleaned up a couple other things: the dealloc funcs don't allow you to
pass in 0.  No one was doing it, and allowing it makes it seems like we
wanted to have that be an option.  perf_alloc_status was renamed.  It had
nothing to do with "struct perf_alloc".  It was trying to get a new status
(a.k.a. to alloc()).  perfmon_install_session_alloc() was needlessly
clever, and the errors() we throw now have real error messages.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoAdd timespec helpers (XCC)
Barret Rhoden [Wed, 8 Jun 2016 15:46:55 +0000 (11:46 -0400)]
Add timespec helpers (XCC)

These are pretty useful.  I used them in timerfd, but now I'd like to
use them in other programs.

Rebuild glibc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Remove the built-in 'sleep' command
Barret Rhoden [Tue, 7 Jun 2016 20:56:59 +0000 (16:56 -0400)]
perf: Remove the built-in 'sleep' command

We can just use the real sleep program at /bin.  Perf now uses the
create_child helpers, so the /bin lookup for sleep happens

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoAdd helpers to create child processes
Barret Rhoden [Tue, 7 Jun 2016 20:12:00 +0000 (16:12 -0400)]
Add helpers to create child processes

Basically everyone who creates a process will want to try to lookup in
/bin and to be able to handle scripts.  Another common usage is to pass
the parent's FDs to the child.

strace now uses this helper, which means we can now strace shell

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoFix sys_proc_create()'s error handling
Barret Rhoden [Tue, 7 Jun 2016 13:20:01 +0000 (09:20 -0400)]
Fix sys_proc_create()'s error handling

I think we were dropping the file's kref for certain errors.  The
handling itself was a little confusing; I prefer the
"error_with_something_to_undo" style here, compared to the

The other main thing is that we return an error early if a file is not
an elf, just like with sys_fork().  This will allow userspace to deal
with shell scripts.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Convert a FILE* instead of a filename
Barret Rhoden [Fri, 17 Jun 2016 16:15:38 +0000 (12:15 -0400)]
perf: Convert a FILE* instead of a filename

This will make perf stat (upcoming patch) easier.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Rewrite the front end interface
Barret Rhoden [Tue, 7 Jun 2016 01:47:34 +0000 (21:47 -0400)]
perf: Rewrite the front end interface

perf.c handles all of the argument processing and the execution of the

The previous implementation wasn't very flexible or extensible, and it
had a bunch of arguments that were different than Linux's perf.

Our new perf acts much more like Linux.  We don't support every option,
and -F is a bit hokey (for now!).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Use Linux-style parsing of the core list
Barret Rhoden [Tue, 7 Jun 2016 01:40:44 +0000 (21:40 -0400)]
perf: Use Linux-style parsing of the core list

-C x,y,i-j,z

No need for the LL cores, the negation, or the all cores.  We do all
cores by default.

This also checks with the kernel to find out how many cores there are
total, instead of allowing people to set for cores that do not exist.
We'll see if that's a bad idea or not.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Fix racy access to cpu_buf->block
Barret Rhoden [Mon, 6 Jun 2016 21:31:57 +0000 (17:31 -0400)]
perf: Fix racy access to cpu_buf->block

Each core has a block that it flushes to the global queue on command.
However, that is per-cpu state that is accessed from perfmon IRQs.  Thus
any unsafe access, such as writing the block to the global queue, should
be protected from concurrent access.  In this case, disabling IRQs is

The bug showed up as a queue with an incorrect length.  The sum of the
BLENs did not add up to qlen (q->dlen, btw).  The last block on the list
was appended to *while* it was on the queue.  This happened due to an
IRQ right after writing to the queue, but before we cleared

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Fix stream corruption issues
Barret Rhoden [Fri, 3 Jun 2016 14:58:19 +0000 (10:58 -0400)]
perf: Fix stream corruption issues

Under heavy load, e.g. perf record -c 1000 /bin/hello (sampling every 1000
unhalted cycles), the stream would get corrupted.  This would appear as an
"Unknown record" or ridiculous sizes/types.

I'm not 100%, but it looks like the profiler_queue was getting broken up
under some circumstances.  The main culprit was probably that when a core
pushed a block into the queue, it would then do its homebrewed overflow
management.  It would rip the *first* block off the queue, instead of just
dropping the new block.  If for some reason we drained only part of that
block, then we just busted the stream.

This situation could happen if the profiler is being read (qread) at the
same time as samples are created.  Say we looked, saw size = 10, then
someone else came in, added a block, and removed the first block.  Now size
= 12.  We read 10, then that last block is split to 2.  Later on, *that*
block gets removed.  Now the stream is broken.

This commit is a 100% fix - there's another bug where the commit stream
and profiler_queue was getting messed with that I'll fix shortly.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoAllow kfunc to take decimals and print the retval
Barret Rhoden [Fri, 3 Jun 2016 14:16:32 +0000 (10:16 -0400)]
Allow kfunc to take decimals and print the retval

Not all functions actually return something.  We're basically just printing
what the caller *thinks* was returned.  On x86, this is just rax.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoAdd a sleep utility program
Barret Rhoden [Thu, 2 Jun 2016 21:10:08 +0000 (17:10 -0400)]
Add a sleep utility program

The motivation is so that perf doesn't need to special-case sleeping.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoFix smp_idle() stack resetting bug
Barret Rhoden [Thu, 2 Jun 2016 16:17:18 +0000 (12:17 -0400)]
Fix smp_idle() stack resetting bug

This started as a page fault in the backtracer while the system was under
heavy PMU interrupt load (every 100 or 1000 cycles).  For those curious,
here's how I sorted it out:

HW TRAP frame at 0xffff80081f7c5ce0 on core 0
  rax  0x0000000000000002
  rbx  0x0000000000000001
  rcx  0x000000000000000f
  rdx  0xffff80081f7c5de8
  rbp  0xffff80081f7c5da0
  rsi  0x00000000006f6770
  rdi  0xffffffffc2052b10
  r8   0x0000000000000000
  r9   0x0000000000000000
  r10  0xffff80082f9c6540
  r11  0x0000000000000202
  r12  0x0000000200000000
  r13  0xffff80082cf5e440
  r14  0xffff80081f7c5f40
  r15  0xffff80082fabb528
  trap 0x0000000e Page Fault
  gsbs 0xffffffffc76e50c0
  fsbs 0x0000000000000000
  err  0x--------00000000
  rip  0xffffffffc211afee
  cs   0x------------0008
  flag 0x0000000000010002
  rsp  0xffff80081f7c5da0
  ss   0x------------0010

Backtrace of kernel context on Core 0:
 #01 [<0xffffffffc211afee>] in backtrace_list
 #02 [<0xffffffffc204a0f9>] in profiler_add_kernel_backtrace
 #03 [<0xffffffffc211f4ba>] in perfmon_interrupt
 #04 [<0xffffffffc2123472>] in irq_dispatch
 #05 [<0xffffffffc2123e2f>] in handle_irq
kernel panic at kern/arch/x86/trap.c:270, from core 0: Proc-less Page Fault in the Kernel at 0x00000000006f6778!
Entering Nanwan's Dungeon on Core 0 (Ints off):

backtrace_list() thought we had a kernel FP == 0x6f67700 (rsi).

What were we BTing?  At that addr (from looking at the asm), rdi is the PC
we had just written, and rdx looks like the pc array.

ROS(Core 0)> kfunc hexdump 0xffff80081f7c5de8 100
ffff80081f7c5de8: 5e 77 05 c2 ff ff ff ff 10 2b 05 c2 ff ff ff ff

There's rdi, which is:

0xffffffffc2052b10 process.c:1150
proc_yield(), scp !being_nice case, around save_context_s

And the first one:

0xffffffffc205775e arch/trap.h:303
set frame pointer, being called from smp_idle (which is clear
from the asm).

The most recent thing written (yield) should be the older on the stack
trace.  Yield does call smp_idle, though not from that exact location.
Probably close enough.

More importantly, we should not be able to backtrace back through an
smp_idle!  We set the frame pointer to 0 in there.

looking more closely:

ffffffffc205775e:   48 89 c5                mov    %rax,%rbp

If we got interrupted here from the PMU and didn't actually run that
instruction, then we didn't reset rbp yet...

Are IRQs disabled during smp_idle?  Looks like no from looking at the code
(which is the bug this commit fixes).  Yet we did reset the stack pointer!
although the FP is still the old one, we jumped ourselves to the top of the
stack, and once we get interrupted, we are actively using it!  That's the
same stack that we're walking back and looking at for the backtrace.
Whoops!  That will clearly trash our backtrace.  (the backtrace should be
looking at parts of the stack below the initial RSP from when we took the

To confirm, let's poke around and see what we can see.

The rsp of the faulting context was 0xffff80081f7c5da0, but that was the
rsp of the running context - not the one that was interrupted.  But if the
theory is right, then that stack should be the same as the one that just

Let's look at the whole stack:

Try kfunc hexdump 0xffff80081f7c5000 0x1000  (remember kfunc takes hex!)

ffff80081f7c5000: ef be ad de 00 00 00 00 00 00 00 00 00 00 00 00

There's the canary at the bottom of the stack.

rdx is 0xffff80081f7c5de8, which is on that page.  (That's a stack-local
array of PCs).  That should be no surprise.  What we'd like to see is that
it's the same stack (although clobbered!) as the original context we were
backtracing.  We'd likely need to look below the backtracer's rsp to see
any evidence.

Here's a chunk below the backtracer's SP.  We'll want to look from the
bottom and work our way up, since this stack has been reused a lot.

ffff80081f7c5cf0: 02 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
ffff80081f7c5d00: 0f 00 00 00 00 00 00 00 e8 5d 7c 1f 08 80 ff ff .........]|.....
ffff80081f7c5d10: a0 5d 7c 1f 08 80 ff ff 70 67 6f 00 00 00 00 00 .]|.....pgo.....
ffff80081f7c5d20: 10 2b 05 c2 ff ff ff ff 00 00 00 00 00 00 00 00 .+..............
ffff80081f7c5d30: 00 00 00 00 00 00 00 00 40 65 9c 2f 08 80 ff ff ........@e./....
ffff80081f7c5d40: 02 02 00 00 00 00 00 00 00 00 00 00 02 00 00 00 ................
ffff80081f7c5d50: 40 e4 f5 2c 08 80 ff ff 40 5f 7c 1f 08 80 ff ff @..,....@_|.....
ffff80081f7c5d60: 28 b5 ab 2f 08 80 ff ff 0e 00 00 00 00 00 00 00 (../............
ffff80081f7c5d70: 00 00 00 00 00 00 00 00 ee af 11 c2 ff ff ff ff ................
ffff80081f7c5d80: 08 00 00 00 00 00 00 00 02 00 01 00 00 00 00 00 ................
ffff80081f7c5d90: a0 5d 7c 1f 08 80 ff ff 10 00 00 00 00 00 00 00 .]|.............

There are a few code pointers on there.  Ones at higher addrs (lower in the
output) were called first, if they were ever actually called.  Sometimes
there's just stuff on the stack.

0xffffffffc211afee kern/arch/x86/kdebug.c:343

0xffffffffc2052b10 kern/src/process.c:1150
Sound familiar?  That's the one from our BT earlier!

Even weirder, kdebug.c 343 is the faulting address of our current context!
I doubt that proc_yield called backtrace like that - more likely it's
leftover from a previous run.  We are hammering the system with backtrace
calls, btw.  The fact that I found the address of a function in the
backtrace on the stack right below where the stack was clobbered is enough
for me to think this was likely the problem.

So the scenario was that we got deep in a syscall (yield), far enough to
make it down the stack that we can see traces of it later.  Then we
smp_idled and got interrupted after setting the stack pointer, but before
setting the frame pointer.  FP was still pointing into the old location,
down the stack, which we are using in the IRQ handler.  Eventually the IRQ
handler clobbers the stack enough that the BT goes wild and PFs.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Remove a few unused bits
Barret Rhoden [Tue, 31 May 2016 19:17:06 +0000 (15:17 -0400)]
perf: Remove a few unused bits

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Save and emit the command line
Barret Rhoden [Tue, 31 May 2016 19:05:44 +0000 (15:05 -0400)]
perf: Save and emit the command line

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Handle generic event types
Barret Rhoden [Sun, 29 May 2016 23:08:16 +0000 (19:08 -0400)]
perf: Handle generic event types

Linux's perf has a bunch of generic, built-in events.  For instance,
'cycles' or 'cpu-cycles' is translated to whatever arch-specific codes
are needed.

Those generic events have a special type, e.g. PERF_TYPE_HARDWARE, that
are part of the perf data ABI.  The generic HW events also happen to
correspond to x86's architectural counters.

Users can now specify the same generic events as perf with Akaros, at
least for the basic hardware counters.  The infrastructure is there if
we want to expand to other types and configs.

To some extent, this is set of event parsing functionality similar to
and somewhat parallel to libpfm4.  The difference is that libpfm4 has
access to all sorts of special counters for particular machines, while
these ones are supported on all machines.  You can still use either pfm
event strings or these generics.  For instance, the following event
strings are equivalent on most Intel machines:

cycles  (generic)
cpu-cycles  (generic alias)
unhalted_core_cycles  (libpfm4)
r3c  (raw)

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Emit build-ids for processes and the kernel
Barret Rhoden [Fri, 27 May 2016 19:20:57 +0000 (15:20 -0400)]
perf: Emit build-ids for processes and the kernel

For the kernel and for every mmap and process, we output a build-id.
The mmaps cover both shared libraries and the actual names of symlinked

For instance, ash shows up as a process named ash as well as an mmap for
the actual binary busybox:

$ perf buildid-list perf.data -Hv  2>&1 | sort
build id event received for /bin/ash: 4eda16d472bcb2b6f610ed21d7036c6599515594
build id event received for /bin/busybox: 4eda16d472bcb2b6f610ed21d7036c6599515594

FWIW, we might not *need* build-ids with perf.  Even with them, you'll
need the absolute latest perf (e.g. late May, 2016) to handle symfs and
build-ids correctly.  Regardless, spitting out build-ids is the way to

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoAdd a build-id to the kernel
Barret Rhoden [Fri, 27 May 2016 21:24:13 +0000 (17:24 -0400)]
Add a build-id to the kernel

Since KFS is linked into the kernel, changes in KFS will result in changes
to the build-id.  That limitations will go away once we support a real

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Port symbol-elf.c
Barret Rhoden [Thu, 26 May 2016 20:36:53 +0000 (16:36 -0400)]
perf: Port symbol-elf.c

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Remove unused parts of symbol-elf.c
Barret Rhoden [Thu, 26 May 2016 16:00:55 +0000 (12:00 -0400)]
perf: Remove unused parts of symbol-elf.c

We actually just need the build-id stuff.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Add Linux perf's symbol-elf.c
Barret Rhoden [Wed, 25 May 2016 20:56:07 +0000 (16:56 -0400)]
perf: Add Linux perf's symbol-elf.c

Unmodified other than a CR header, from commit c13c81006314 ("Merge tag
'rtc-v4.2-1' of

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoAdd elfutils to the distribution
Barret Rhoden [Wed, 25 May 2016 20:25:21 +0000 (16:25 -0400)]
Add elfutils to the distribution

Perf will depend on this.  We don't have a way to express that dependency
yet, but at least we'll build the library before building perf when you do
a make apps-install.

Note that elfutils isn't added to our codebase - just a Makefile that will
build it and drop it in your sysroot.

You'll need to make fill-kfs after building this, just like any other
shared library (e.g. glibc).

Oh, this also accidentally gave us readelf and a bunch of other tools that
should run natively.  Right now, they are installed to the sysroot/usr/bin
instead of kern/kfs/bin.  We probably don't want an extra 11 MB for tools
we won't use yet.

I attempted to have make depend on $(build-dir)/Makefile instead of
config.  This would work for a clean repo, but later we'd have issues.
If we had successfully configured, then did something that caused a
reconfig, make would get confused.  It would see that
$(build-dir)/Makefile existed, then it would rebuild build-dir, removing
the Makefile.  It would skip the config step, since it thought that
build-dir was older than Makefile, for whatever reason.  i.e.

Prerequisite `elfutils-0.164' is older than target `elfutils-0.164/Makefile'.
No need to remake target `elfutils-0.164/Makefile'.

If someone has a nice fix, then we can change it.  Until then, every
time we make, we'll also have to configure.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoExport AKAROS_{SYSROOT,PREFIX} from tools/Makefrag
Barret Rhoden [Wed, 25 May 2016 20:24:01 +0000 (16:24 -0400)]
Export AKAROS_{SYSROOT,PREFIX} from tools/Makefrag

Libraries that build with tools/Makefrag will need this.  Apps get
installed to KFS.  Libraries go into the toolchain.

People ought to start setting AKAROS_XCC_ROOT.  If not, we'll try to detect
it, assuming you built with a Makelocal.  Eventually, all of this will get
replaced with a proper package management system.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoHave gcc link all binaries with --build-id (XCC)
Barret Rhoden [Thu, 26 May 2016 15:25:24 +0000 (11:25 -0400)]
Have gcc link all binaries with --build-id (XCC)

Everything linked with gcc will now have a build-id note.  This does not
affect the kernel, since we use a linker script for linking it.

Rebuild gcc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoUse gnu-user command line options for gcc (XCC)
Barret Rhoden [Thu, 26 May 2016 14:26:14 +0000 (10:26 -0400)]
Use gnu-user command line options for gcc (XCC)

We're mostly like the gnu-user config.  We don't use their gcc/config
exactly, but we take most of the parts.  We weren't taking their command
line options though, which was a problem.

If you tried to build with -rdynamic, gcc would complain.
-Wl,--export-dynamic would work, and it was just the lack of option parsing
on our part.

Thanks to James Knight for the tip to look at the opts file.

Rebuild gcc.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agox86: Fix relocation error in vcore_asm.S
Barret Rhoden [Wed, 25 May 2016 23:09:41 +0000 (19:09 -0400)]
x86: Fix relocation error in vcore_asm.S

The original code worked, but would generate a 64 bit relocation for
some programs that we could have trouble with.  This popped up from a
./configure test when building a __thread example.

My original fix for it was to do this:

movabs $(__kvc_entry_c), %rax
call *%rax

Which is what we do in the kernel.  The problem with that is it generates a
TEXTREL (relocation entry in a text segment), which messes up a lot of
modern programs and security policies.  For a good overview, check out:


The current code seems to work - we'll see if we have problems in the
future.  While we're here, I also fixed that while 1 loop (which we never
hit.  jb 1 isn't what we wanted there...).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Emit COMM records for existing processes
Barret Rhoden [Wed, 25 May 2016 18:28:45 +0000 (14:28 -0400)]
perf: Emit COMM records for existing processes

We were emitting COMMs for new processes and MMAPs for old processes, but
not COMMs for old processes.  This meant that samples for existing
processes (e.g. during a sleep 10) would only have the PID, but not the
name of the process.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Add infrastructure for creating headers
Barret Rhoden [Wed, 25 May 2016 18:05:50 +0000 (14:05 -0400)]
perf: Add infrastructure for creating headers

Many headers follow a common pattern.  Get some info from somewhere.  Put
it in a header structure, which we later emit in the features section.

This adds some support functions and a couple examples of headers that we
can emit.  One notable difference is that headers are a list of memblocks.
That way, you can add multiple memblocks if it's easier (it might help with
build ids).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoFix #version's stat
Barret Rhoden [Wed, 25 May 2016 16:29:18 +0000 (12:29 -0400)]
Fix #version's stat

The stat length in the devtab is 0 for all strings.  We should be reporting
the length of what you can read, which is strlen + 1 (for the \0).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoRemove the \n from #version variables
Barret Rhoden [Wed, 25 May 2016 17:25:35 +0000 (13:25 -0400)]
Remove the \n from #version variables

It's a pain to have that \n for tools that use the output of these strings,
and it doesn't really help for interactive users either.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Remove the xmem_arena allocator
Barret Rhoden [Wed, 25 May 2016 15:33:38 +0000 (11:33 -0400)]
perf: Remove the xmem_arena allocator

It might have had a performance benefit, but it cluttered up the code and
forced us to pass memfile pointers around when we shouldn't need to -
specifically to mem_block_alloc().

The only thing that was called a lot was mem_block_alloc(), which now is
just a malloc under the hood, and the only existing time it was used was in
mem_file_write(), which already attempted to avoid malloc calls.

Now I can call mem_block_alloc() without worrying about the memfile.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Fix the perf.data file output
Barret Rhoden [Tue, 24 May 2016 20:20:03 +0000 (16:20 -0400)]
perf: Fix the perf.data file output

The main problem was that the features headers (e.g. HEADER_HOSTNAME) just
didn't work at all.  The headers are supposed to have a perf_file_section
for each header, which they were missing.  The other header issue was that
the feature header section is supposed to be after the data section.  The
three big sections (attrs, data, event_types) all have file sections in the
main header, but the features are just assumed to be after the data
section (based on linux perf's code).

The latter bit implies that the data section is last among the three
sections.  Who knows what the order for them really is, but since they all
have perf_file_sections, then we should be good with just keeping data

The other major thing that seemed messed up was the rel_offset.  The old
code was just looking at it once and using it for all of the three big
sections.  Each section has its own peculiar relocations.  The trickiest
is that the attr MF's relocs are all relative to the attr_id MF.  Yikes.
I think we were getting away with it since attrs was the only one with

Other than that, there's just some cleanup.  For instance, when setting a
feat header, we should set the PH bit then instead of deferring it.  And
when building the perf_file_sections for the three big sections, we should
always do it, not condition on size > 0.  Just set the damn values.  That
clarifies and simplifies the code a lot, instead of having some mysterious
'rel_offset' sitting around.  'rel' to what?

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Build with warnings and -Werror
Barret Rhoden [Mon, 23 May 2016 21:58:47 +0000 (17:58 -0400)]
perf: Build with warnings and -Werror

And fixes a few warnings.  I noticed this when the compiler didn't complain
about obviously wrong debug code...

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Clean up attr production
Barret Rhoden [Tue, 24 May 2016 16:15:36 +0000 (12:15 -0400)]
perf: Clean up attr production

We had been using just the raw_info from the kernel to generate the attrs.
That meant that we'd need to keep track of which events we had seen before
(hash table, though since we only ever had one or two events, that might
have been overkill), and we lost information from the original event

Now we use the perf_eventsel pointer as the raw_info / user_data, and we
can just emit an attr based on what was originally submitted.  That will
also allow us to support some of the generic hardware events in the future.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Use a user_data blob for perf_event (XCC)
Barret Rhoden [Mon, 23 May 2016 18:37:26 +0000 (14:37 -0400)]
perf: Use a user_data blob for perf_event (XCC)

Previously, the kernel had to emit something that perfconv could interpret
as-is to build a perf_event stream.  That was limiting.  Now, the user can
pass a blob with a perf_event that the kernel will send whenever the event
fires.  Basically user_data becomes the info field in any perfmon sample.

The user can do whatever they want with this - it can even be the original
event code if they choose.

Right now, perfconv doesn't know how to handle this new format.  That'll be
sorted out next patch.

Reinstall your kernel headers.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Track the perf_context when converting
Barret Rhoden [Mon, 23 May 2016 16:48:45 +0000 (12:48 -0400)]
perf: Track the perf_context when converting

perfconv.c was originally its own program, completely decoupled from the
rest of perf.  It got its info from the kernel only, which limits the
things we can do with it.  For instance, any accounting info or parameters
for a perf event would need to be communicated to the kernel and then
shipped back out to userspace to be reported.  This design is rather

Now we'll keep track of the perf_context, so that we can look up the
original perf_event during conversion time.  This is similar to tracking
the perf_event_attr throughout the life of the perf run.  That's something
Linux does internally, so it makes sense for us to do it in our perf.

For an example of where the old system failed, we don't know the
sample_period for any given event.  The kernel only gives us 64 bits per
event, and that doesn't include pev->trigger_count.  That was submitted to
the kernel, but subsequently lost.  Userspace still knows what it asked
for, and the kernel also knows, but it disappears as we flow through the

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Enable and disable counters in one step
Barret Rhoden [Fri, 20 May 2016 18:40:56 +0000 (14:40 -0400)]
perf: Enable and disable counters in one step

Perf counters needs to be enabled in two MSRs: the global and the specific
(fixed or eventsel).  We had been clumsily splitting these calls.  Instead,
we can just do it in one move, which clears up the code itself.

For now, we track whether a counter is available/in-use by the specific
MSR.  Because of that, we need to clear both registers when disabling the
counter.  If we do something else in the future, we can disable by only
setting the global MSR, which is one of the benefits of intel's version 2.

Also, this commit makes better use of helpers to check if a counter is
available.  Doing the bit shifts in place was unclear and the source of
multiple bugs.  I caught one of them during Davide's first code submission,
but missed the other (which I fixed a few commits back).  Had we used a
helper the whole time, we only would have needed to fix it once.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Fix event enabling logic
Barret Rhoden [Fri, 20 May 2016 16:25:21 +0000 (12:25 -0400)]
perf: Fix event enabling logic

There were a bunch of subtle problems here.

First, we should never write 'pa' in perfmon_do_cores_alloc(), or anywhere
that is shared and racy.  But you'll notice that technically we weren't:

PMEV_SET_EN(cctx->fixed_counters[i].event, 1);

That's the local copy.  But, when we called the function that would have
used the Enable bit, we actually used the old shared one again!

tmp = perfmon_get_fixevent_mask(&pa->ev, i, fxctrl_value);

So now we just copy in and use a local variable, and to keep things clear,
we don't make changes to the event on a per-core basis.  If we have to in
the future, we'll operate on the local copy.

Second, the meaning of the Enable bit was wrong for fixed counters - it was
setting the interrupt (PMI).  We have a separate bit for that.

Third, it wasn't clear why we needed to enforce that Enable was on.  It's a
nice thing to do, but it looks like we need at least one bit set so the
kernel doesn't get confused about whether a counter is being used or not.

Next (fourthly?), we weren't clearing the overflow when we wanted an
interrupt.  If we ever had a situation where the counter had an old
overflow (say, it wasn't in sampling mode and just happened to overflow),
then we wouldn't get our interrupt.  We were doing this when we received an
actual interrupt - just not when we first set it up.  While we're at it, we
should be clearing overflow regardless of whether or not we want an
interrupt.  The regular counting style counter should track that too.

While we're at it, we shouldn't set trigger_count to whatever the user
asked for if the interrupt isn't on.  They probably said 0, but we might as
well make sure it is 0.

Finally, the perf counters need to be enabled twice.  We were doing it, but
for some reason we'd enable it in one place, then set some values, then set
it in the other place.  Technically the counter isn't enabled until this
last setting, but it's pretty ugly.  Now we just set the counter settings,
then turn it on.

It's also just nasty to have:

perfmon_enable_fix_event((int) ccno, FALSE);

Enable?  No, actually disable!  There are now two functions for that.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Fix GPF when writing fixed trigger counters
Barret Rhoden [Fri, 20 May 2016 15:34:02 +0000 (11:34 -0400)]
perf: Fix GPF when writing fixed trigger counters

There are a bunch of bits reserved in fixed counters.  We must set the
upper ones to 0.  We'll still overflow properly; the register is just

The unfixed perf counters also have a width, but I didn't get a GPF when
setting the upper bits.  Still - we should do the right thing and not set
those upper bits.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Fix fixed counter busy detection
Barret Rhoden [Thu, 19 May 2016 22:36:24 +0000 (18:36 -0400)]
perf: Fix fixed counter busy detection

We're supposed to shift the mask to the right spot, which is the index
times the width of the mask.  E.g. for fixed counter 1, we want to look at
the 4 bits shifted in by 4.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Use tracked event info for output
Barret Rhoden [Thu, 19 May 2016 22:03:28 +0000 (18:03 -0400)]
perf: Use tracked event info for output

The event selector knows all about an event: its name, flags, raw code,
etc.  We can use that when we're outputting the event later on.  We had
been getting some info from the kernel and copying into sel, but that's
actually lies - AFAIK, those values are all just 0.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Use libpfm4 and Linux style event strings
Barret Rhoden [Thu, 19 May 2016 20:04:18 +0000 (16:04 -0400)]
perf: Use libpfm4 and Linux style event strings

We had been using a custom event string, which was incompatible with both
Linux's perf and libpfm4.

Now, we accept any libpfm4 string, and barring that, we'll use perf-style
raw codes.  We accept pfm4-like modifiers, such as :u and :k.  Unlike perf,
we require that each modifier/token is separated by :.

So this works:

-e inst_retired:u:k

But this doesn't:
-e inst_retired:uk

That's actually libpfm4, not us.  I do the same thing for the raw codes
though, since we might as well be consistent (and simple).

In the process, I also fixed a couple issues with event specification.

Many events from libpfm4 are more than 8 bits long.  The old code assumed
that the event was 8 bits and the mask was 8 bits.  That meant that we
could submit events like 0x13c properly (you'd have to write it as
0x3c:0x01, even though perf list told your 0x13c).  Surprise!  Now we allow
longer event selectors, where the upper bits are the mask.  That's just
what libpfm4 expects, and really it is how the hardware (and OS interface)
are programmed.

The other issue is pseudo-encoded events.  On most Intel machines, libpfm4
returns the event 0x300 for unhalted_reference_cycles.  That's not a real
code, and will silently fail.  It needs to be the fixed counter 2.  Linux
knows this, but we weren't interpreting it.  Without these changes,
attempts to use unhalted_reference_cycles would simply return 0 for the
perf counters.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoRemove the BUILD_INFO_FILE variable
Barret Rhoden [Fri, 13 May 2016 18:31:38 +0000 (14:31 -0400)]
Remove the BUILD_INFO_FILE variable

This allowed developers to specify their own .c file for the build info,
instead of using whatever is generated by make/kbuild.  That seems like a
potential mess, since there's nothing keeping those make files in sync
with build_info.{c,h}.  And it doesn't seem particularly useful.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoRemove kernel path and hostname from #version
Barret Rhoden [Fri, 13 May 2016 18:16:55 +0000 (14:16 -0400)]
Remove kernel path and hostname from #version

Perf had been using the kernel path so that it could emit it in
perf.data.  We no longer need that.  The kernel path was the path on the
machine on which the kernel was built, which assumes the perf report would
be analyzed on that same machine.

Likewise, this removes the hostname from #version.  This hostname wasn't
the name of the Akaros machine; it was the name of the machine on which
Akaros was built.  I don't see a good reason to keep this around.

If we need either of these in the future, we can probably replace it with
build-id (from the linker).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoRemove snc
Barret Rhoden [Fri, 13 May 2016 16:51:17 +0000 (12:51 -0400)]
Remove snc

Now that we have ssh, we don't need snc.  If we ever do, we can revert this

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Remove the perf_patch
Barret Rhoden [Fri, 13 May 2016 16:44:40 +0000 (12:44 -0400)]
perf: Remove the perf_patch

We no longer need to patch Linux's perf.  We should be ABI compliant with
PERFILE2.  If not, it's a bug.

This also updates Documentation, at least where it is related to setup.
There's a lot more TODO here.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Treat the kernel like [kernel.kallsyms]
Barret Rhoden [Fri, 13 May 2016 16:08:35 +0000 (12:08 -0400)]
perf: Treat the kernel like [kernel.kallsyms]

The perf ABI knows about the kernel, and there are bits in the data format
for kernel mmaps and traces.  When we run Linux's perf report, we can point
it at our symbol table and it can resolve the symbols.

Previously, we were treating the kernel like it was a user binary and had
to hack up Linux's perf to handle it accordingly.  Now we're just emitting
the right thing.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Set sample_period
Barret Rhoden [Fri, 13 May 2016 15:42:20 +0000 (11:42 -0400)]
perf: Set sample_period

Newer versions of perf need the sample_period.  Without it, all the
percentages in perf report are 0.

The sample period should be how many samples it takes to trigger an event
(e.g. overflow IRQ on a perf counter).  Perhaps we should always have been
saying at least sample_period = 1 (i.e. an event notif for every event).

We don't keep track of the actual period from perf's invocation.  We could
if we wanted to, but since percentages are relative, it's not a big deal at
this point.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Fix memory leak in the profiler
Barret Rhoden [Thu, 5 May 2016 16:14:24 +0000 (12:14 -0400)]
perf: Fix memory leak in the profiler

qclose() just closes it.  qfree() does a qclose() and a kfree().

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Use tools/Makefrag for building perf
Barret Rhoden [Thu, 5 May 2016 15:38:18 +0000 (11:38 -0400)]
perf: Use tools/Makefrag for building perf

This allows us to cd into tools/profile/perf and build it directly.
Previously, it only was buildable from the top-level Makefile and only when
building all apps.

You can still build it from the top-level (apps-install).

Also, the usage of CFLAGS_USER is a little sketchy.  Those cflags were
originally for parlib and related libraries.  We use them for tests, though
that might be unnecessary.  Apps should use their own cflags.  If there is
some critical flag that every userspace app should have, then it should be
set in the toolchain in gcc (e.g. -mno-red-zone, RIP).

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoperf: Fix perf's argv[] usage
Barret Rhoden [Thu, 5 May 2016 15:37:20 +0000 (11:37 -0400)]
perf: Fix perf's argv[] usage

Conflicting with sys_proc_create(), and driven by using excessive consts in
the signature for main().

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agovmm: Only map as much data as you read in.
Ronald G. Minnich [Wed, 8 Jun 2016 22:01:57 +0000 (15:01 -0700)]
vmm: Only map as much data as you read in.

The current vmrunkernel sets up 1 Gbyte of 2M pages.
It is best if we can start the kernel with the minimum amount
of page tables set up. That way, if some very bad addressing happens
in early assembly, we'll see it right away as a triple fault.

We now only set up enough 2M pages to cover the size of the file
we read in.

We had thought we might want to dial it back to 4k pages,
but it turns out guests are pretty careful not to turn off
paging attributes that are enabled; rather, they carefully set up
page tables and then enable what they need, not disabling
anything that might have been set up.

Change-Id: I1c9f458f6147e81cd7bf0c51745167a6ff17db79
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
[minor formatting]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agovmm: Make 60K of low 1M available in e820map.
Ronald G. Minnich [Wed, 8 Jun 2016 22:01:56 +0000 (15:01 -0700)]
vmm: Make 60K of low 1M available in e820map.

Linux needs to be able to allocate several pages in low memory.
We had hoped to get around this limit, but it's not possible.

The range 0 to 16M was formerly marked as E820_RESERVED.
Set up 60K of memory (4K->64K) as E820_RAM for guest use.
Continue to leave the 0-4k region as E820_RESERVED, as well
as 64K to 16M.

Change-Id: Icd48bb8b7d6501269d3edb6a8e5b1d7899826a50
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agovmm: Properly set CR4 SHADOW and GUEST_HOST_MASK registers.
Ronald G. Minnich [Wed, 8 Jun 2016 22:01:55 +0000 (15:01 -0700)]
vmm: Properly set CR4 SHADOW and GUEST_HOST_MASK registers.

Set the SHADOW register to 0, and set the GUEST_HOST_MASK
to CR4_VMXE. This ensures that the guest can set the
CR4_VMXE in its CR4 copy to 0, which Linux wants to do.
This eliminates the patch we used to need in Linux
in the early startup assembly code (head_64.S).

Change-Id: I8ee64a5485abef1b5c1d8b07a705f0642335a038
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agouser/vmm: add translation helpers for guest kernel va to pa.
Ronald G. Minnich [Mon, 6 Jun 2016 17:36:40 +0000 (10:36 -0700)]
user/vmm: add translation helpers for guest kernel va to pa.

These are two simple translation helpers, one for converting
an arbitrary guest kernel virtual address to a physical
address (and hence host process virtual address); and one
to return the guest kernel RIP as a physical address (and hence
host virtual address).

Currently, they just blow the upper 34 bits of the guest
VA to zero, since the high part of the negative address
space is low physical memory.

Longer term, we may need to walk page tables, but so
far there has been no need.

Change-Id: I6f3875b03b7b33edd223615bd4678e6f2641d90a
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agouser/vmm: print RIP and hexdump of RIP[0:16] on failed vmexit handling.
Ronald G. Minnich [Fri, 3 Jun 2016 20:45:32 +0000 (13:45 -0700)]
user/vmm: print RIP and hexdump of RIP[0:16] on failed vmexit handling.

Sometimes the current status dump is not quite enough for debugging.
One example is when the RIP somehow ends up with a weird value,
e.g. the middle of allocated memory, and that code is hence
not visible in the disassembled kernel.

The exit now prints a bit more information, and a hex dump of
the 16 bytes starting at RIP. This little extra bit of information
allowed me to figure out a strange problem I was having.

Change-Id: Ic37396d48bfe8934d7943e9ac6729540468badfa
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoVMM: clean up IO emulation.
Ronald G. Minnich [Fri, 3 Jun 2016 20:45:31 +0000 (13:45 -0700)]
VMM: clean up IO emulation.

The io emulation code was written early in the game and was not correct
in several ways.

The big change is that we DO note that an IO address is not supported
but DO NOT consider it an error. The hardware does not, and we should
not. We do log a message to stderr that there was IO to an unsupported
address, but people commonly do such IO operations to implement, e.g.,
timing loops. It's perfectly legal to do IO to nonexistant config space
registers, as well, so it makes no sense to check those either. We can't
assume that an IO to a bogus address or config space register is not
intended or mistaken.

There is only one error return from the io() function: IO instructions
we did not handle because we could not interpret them. In that case, the
function really has no option but to return false. In all other cases,
it should return true.

As a result, all the configread/write functions become void, io() itself
now returns a bool, and handle_io returns what io returns.

We should consider changing regp() so that writes "to air" go to a
different place than reads "from air", as one might argue that reads
"from air" should return all 1s. In real hardware, not even this
reasonable rule always applies, so it's hard to make a strong argument
either way.

Change-Id: Ifec56655528f748183a35663c8ef20b8bc486b35
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoIncorporate new functions into glibc and expose to userland (XCC)
Dan Cross [Thu, 2 Jun 2016 22:28:20 +0000 (18:28 -0400)]
Incorporate new functions into glibc and expose to userland (XCC)

Add an Akaros-only sysdeps/akaros/bits/{stdlib,string}-akaros.h
with prototypes for reallocarray and strlcpy and strlcat respectively.
Modify sysdeps/stdlib.h and sysdeps/string.h to include those headers,
respectively.  Modify Makefile and Versions to export these functions.

Rebuild glibc.

Tested: Wrote, compiled and ran a C program that used all three functions.
Change-Id: Ie1c86c261c398f2db67b1968d51e446b84e42293
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoPristine versions of headers added to sysdeps/akaros/bits.
Dan Cross [Thu, 2 Jun 2016 22:23:50 +0000 (18:23 -0400)]
Pristine versions of headers added to sysdeps/akaros/bits.

Import unmodified versions the stdlib/stdlib.h and string/string.h
from the upstream glibc-2.19 tree.  These will be modified to include
'bits' files; this commit is intended to keep the diff short.

Change-Id: I31454d577dd1172f054eeedc74273925a11fa8c1
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoImport from OpenBSD: clang-format, naming and symbols, checkpatch clean
Dan Cross [Thu, 2 Jun 2016 22:23:49 +0000 (18:23 -0400)]
Import from OpenBSD: clang-format, naming and symbols, checkpatch clean

Run clang-format on new sources from OpenBSD and make them
'checkpatch clean': this involved one small change in strlcpy.c
to move an assignment outside of a conditional.

Replace the OpenBSD 'DEF_WEAK' macro invocations with 'weak_alias',
as per other library code.

Change-Id: Ifc3520f5f486a144de26329b4fe45c700b755047
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoImport from OpenBSD: strlcat, strlcpy, reallocarray.
Dan Cross [Thu, 2 Jun 2016 21:30:44 +0000 (17:30 -0400)]
Import from OpenBSD: strlcat, strlcpy, reallocarray.

We have these utilities in the kernel.  Import them into
the userland.  This is the initial import; these are
unmodified original copies taken directly from the OpenBSD
CVS repository.  Each file has a specific version number
in it.

Change-Id: I812c74f7e5101059f719e0eb002dbed11a732660
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoIntercept CPUID calls to act like KVM
Gan Shun [Wed, 1 Jun 2016 22:31:21 +0000 (15:31 -0700)]
Intercept CPUID calls to act like KVM

Intercept the CPUID vmexit to possibly either set the hypervisor bit or to
return the KVM signature depending on the value in RAX.

Signed-off-by: Gan Shun <ganshun@gmail.com>
Change-Id: Ic27e05eafa22b0a20a888397c8bae37ff0ea3267
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoRemove hardcoded virtio mmio base address and reduce device size
Gan Shun [Wed, 1 Jun 2016 20:22:34 +0000 (13:22 -0700)]
Remove hardcoded virtio mmio base address and reduce device size

Each virtio mmio device page is only 0x100 in size, not counting the
config space. The config space is pretty small and I've seen other
examples use either 1K or 0x200, which should be more than enough.
Also made the commandline parameter take in its address from the device
struct instead of a fixed string value. The virtio_devices start from
the next 512 GB boundary to shortcut the page table walk and fault

Bug: 29003537
Fixes: #5, b/29003537
Tested: Ran and booted a linux guest.

Signed-off-by: Gan Shun <ganshun@gmail.com>
Change-Id: I8391efe930fe5b3f7bd29fd37ff7ae572778d25c
[minor formatting]
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoModify `ifconfig` to use full pathname to 'bind' command.
Dan Cross [Tue, 31 May 2016 22:01:26 +0000 (18:01 -0400)]
Modify `ifconfig` to use full pathname to 'bind' command.

As I work on getting bash integreated into Akaros, modify
`ifconfig` so that it uses the full path to the `bind` command
instead of relying on $PATH: this prevents conflicting with
the builtin `bind` in bash.

Change-Id: I5ab1d57a3d4d5f500a2d989ad0b7c6e8d632f3de
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
4 years agoGet rid of ersatz ARRAY_SIZE macros in code we control.
Dan Cross [Tue, 31 May 2016 21:20:12 +0000 (17:20 -0400)]
Get rid of ersatz ARRAY_SIZE macros in code we control.

These are defined in third_party code, but in code that we control,
replace these with calls to our COUNT_OF macro.

Change-Id: I862e7a6b240b085b205fd881ce3c0789baadc649
Tested: Built user and tests.
Signed-off-by: Dan Cross <crossd@gmail.com>
Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>