akaros.git
6 years agoAdd userspace spinlock implementation
Kevin Klues [Fri, 14 Dec 2012 22:45:09 +0000 (14:45 -0800)]
Add userspace spinlock implementation

6 years agoNeeded to remove -lparlib from cp30's Makefrag
Kevin Klues [Fri, 14 Dec 2012 20:35:24 +0000 (12:35 -0800)]
Needed to remove -lparlib from cp30's Makefrag

6 years agoRemove force_parlib_symbols.
Kevin Klues [Fri, 14 Dec 2012 04:24:04 +0000 (20:24 -0800)]
Remove force_parlib_symbols.

BAM.

6 years agoUse --whole-archive instead of -u for -lparlib
Kevin Klues [Fri, 14 Dec 2012 04:21:50 +0000 (20:21 -0800)]
Use --whole-archive instead of -u for -lparlib

For reasons unknown, dynamically-linked busybox simply failed to respond
to keypresses with -u force_parlib_symbols as the mechanism to force
linkage against libparlib--even though the symbols appeared not to be
weak!  This other mechanism works, and it's also cleanear since we can
remove force_parlib_symbols.

6 years agoremove old bthread library
Kevin Klues [Fri, 14 Dec 2012 03:52:57 +0000 (19:52 -0800)]
remove old bthread library

We don't use bthreads anymore, and some symbols conflicted
with those in libpthread.

6 years agoFixes mmap assertion check
Barret Rhoden [Thu, 13 Dec 2012 22:33:31 +0000 (14:33 -0800)]
Fixes mmap assertion check

Check for MAP_FAILED (-1), not 0, like other allocations...

6 years agoUserspace slab allocator
Barret Rhoden [Tue, 11 Dec 2012 00:42:36 +0000 (16:42 -0800)]
Userspace slab allocator

Note the caches lock use MCS-PDR locks, which for now call malloc() when
initializing.  So you can't currently use the slabs for something that
you need to implement malloc().

6 years agoAdded force_parlib_symbols as default param to gcc
Kevin Klues [Mon, 10 Dec 2012 23:23:53 +0000 (15:23 -0800)]
Added force_parlib_symbols as default param to gcc

Allowed us to remove the busybox patch that diabled looping over
included libs and not including them if they wre not needed.

We previously had to override this because we always wanted parlib
included, but now it is included by default as part of invoking gcc.

6 years agoAdded gcc compiler magic to get libgomp to build for akaros
Kevin Klues [Wed, 5 Dec 2012 04:31:18 +0000 (20:31 -0800)]
Added gcc compiler magic to get libgomp to build for akaros

Still need to implement stubs for pthread_key nonsense, but hopefully
after that, things will just work.

6 years agoMake exit call _exit instead of syscall directly
Kevin Klues [Wed, 5 Dec 2012 04:27:14 +0000 (20:27 -0800)]
Make exit call _exit instead of syscall directly

Needed to get libgomp to work correctly because it required its call to
exit() to be for a function that had a noreturn attribute.  Arguably, we
should have been doing this all along, and the direct syscall was
probably extreme legacy code before we had glibc properly integrated.

6 years agoMake procinfo.h c89 compliant (i.e. no gnu99isms)
Kevin Klues [Wed, 5 Dec 2012 04:25:11 +0000 (20:25 -0800)]
Make procinfo.h c89 compliant (i.e. no gnu99isms)

6 years agoChange default directory for installing riscv
Kevin Klues [Wed, 5 Dec 2012 04:24:10 +0000 (20:24 -0800)]
Change default directory for installing riscv

6 years agoImplemented a few more stubs for PTHREAD compliance
Kevin Klues [Wed, 5 Dec 2012 04:23:06 +0000 (20:23 -0800)]
Implemented a few more stubs for PTHREAD compliance

(Including signal stuff)

6 years agoAdd semaphore stuff for pthreads
Kevin Klues [Wed, 5 Dec 2012 04:21:27 +0000 (20:21 -0800)]
Add semaphore stuff for pthreads

6 years agoSpinlock irqsave usage checks
Barret Rhoden [Thu, 15 Nov 2012 19:46:32 +0000 (11:46 -0800)]
Spinlock irqsave usage checks

Controlled with CONFIG_SPINLOCK_DEBUG.  One big issue is that we usually
need locks to tell ourselves about the deadlock - print locks, kmsgs
locks, etc.  We'll need something else to deal with this.

Here's a list of all irqsave locks.  A few of them weren't even
initialized.  Others probably don't need to be irqsave.  And a few are
from some really ancient code.  Some of these were only detected at
runtime by the usage checks.

Take a look at these and any of your other locks, and fix them up
accordingly.

 /* sync stuff */
 barrier->lock
 list->lock (checklists)

 /* page allocation / coloring */
 cache_colors_lock
 colored_page_free_list_lock (arch dependent btw)

 /* slab allocator */
 cp->cache_lock
 kmem_caches_lock

 /* riscv/sparc */
 fesvr_lock
 cas_lock (needs attention, might not compile)

 /* console printing and reading */
 lock (x86 console lock, cons_putc needs renamed)
 output_lock (serializes all printks)
 print_info_lock (testing.c)
 ptf_lock (x86 trapframe printing lock)
 readline_lock

 /* kmsg */
 per_cpu_info[i].immed_amsg_lock
 per_cpu_info[i].routine_amsg_lock

 /* misc */
 arsc_proc_lock
 systrace_lock (does this need irqsave?)
 ucq hash locks
 packet_buffers_lock

6 years agoSemaphores and CVs have irqsave initializers
Barret Rhoden [Thu, 15 Nov 2012 18:34:29 +0000 (10:34 -0800)]
Semaphores and CVs have irqsave initializers

We also now assert we can block when blocking.  We don't enforce the
spinlock checks yet.

6 years agoNo longer inlines spin_lock
Barret Rhoden [Thu, 15 Nov 2012 03:40:08 +0000 (19:40 -0800)]
No longer inlines spin_lock

Arch-specific locking is done in __spin_{lock,unlock,init}.  Debugging
and whatnot is all done in k/s/atomic.c.

Also adds irq_okay fields and different types of spinlock inits, based
on whether or not it is okay to use the lock in IRQ context or not.  We
don't enforce anything yet (wait for the next patch or three).

6 years agoAsserts/checks for early RKMSG context
Barret Rhoden [Wed, 14 Nov 2012 23:53:04 +0000 (15:53 -0800)]
Asserts/checks for early RKMSG context

The kernel tracks if it is in 'early routine kernel message context,'
which is an RKMSG before it blocks.  Once it blocks/kthreads, the core
leaves that context (in smp_idle), never to return for that kthread.
When the kthread starts up again, it'll be in default context.

Other than allowing us to assert messages that must be routine are in
fact routine, we can detect when a kmsg blocked, thus removing the
restriction on kmsg handler writers to put smp_idle at the bottom of
their functions.

There might be a better way to do this (permanent kthreads, track
whether it blocked in there?), but the basics are the same: when we come
back in to PRKM, we need to detect if we blocked or not, and if so, we
smp_idle.  And if not, we clear whatever flag we were using.  And that
same flag gets cleared in smp_idle as well.

6 years agoKernel context (IRQ, etc) tracking
Barret Rhoden [Wed, 14 Nov 2012 23:29:02 +0000 (15:29 -0800)]
Kernel context (IRQ, etc) tracking

We can now detect what sort of context we are in.  The main use for this
is deadlock detection.

RISC/SPARC people, take a look at your architectures please.

6 years agoKernel message overhaul
Barret Rhoden [Tue, 13 Nov 2012 22:31:12 +0000 (14:31 -0800)]
Kernel message overhaul

We no longer run routines from the IRQ handler, and no longer run
immediates from PRKM().

The difference in the former is in cases where we are in userspace and
we receive an IPI to run kernel messages.  Previously, we handled the
routine messages in the IRQ handler.  Now we do nothing, and handle them
"on the way out" (in the proc_restartcore() / smp_idle() path).

The differences in the latter are that we simply wait til we actually
get the KMSG IPI to run the immediate handlers.  Note there is no
ordering guarantees between different KMSG classes.

6 years agoMakes kmsg code arch independent
Barret Rhoden [Tue, 13 Nov 2012 22:01:37 +0000 (14:01 -0800)]
Makes kmsg code arch independent

Should be no change to functionality.  SPARC/RISCV people: see if this
works for you.  I don't have a working RISCV compiler, and does anyone
even use SPARC?  =)

6 years agoRISCV/SPARC: send_ipi() takes a vector
Barret Rhoden [Tue, 13 Nov 2012 21:52:07 +0000 (13:52 -0800)]
RISCV/SPARC: send_ipi() takes a vector

We could either make an arch-function that is "send a kernel message
IPI", which is what the current versions are doing, or extend send_ipi()
to take other vectors.

Since we might have other IPI vectors in the future, I went with this.
If it's something that is completely impossible for these architectures,
then we can do something else.

Haven't compiled this btw - I still can't run the RISCV compiler on my
machine.

6 years agox86: send_ipi takes an OS coreid
Barret Rhoden [Tue, 13 Nov 2012 21:07:35 +0000 (13:07 -0800)]
x86: send_ipi takes an OS coreid

Instead of a hw_coreid, making like the other architectures.

6 years agoKMSGs no longer self-ipi for routine messages
Barret Rhoden [Sun, 11 Nov 2012 09:07:22 +0000 (01:07 -0800)]
KMSGs no longer self-ipi for routine messages

We used to need this when we had routine messages that popped into
userspace.  The self-ipi forced us to trap back into the kernel to
process the rest of the messages.  Now that our proc management kmsgs
all return (let alone not popping into userspace), this isn't a concern.

We can still have kmsgs that don't return (like __launch_kthread()),
since we'll always run our routine KMSGs at some point in the future
(smp_idle() or proc_restartcore()).

I'd normally wait til combining all the KMSG code to do this, but the
non-x86 arches didn't have ipi_is_pending().

6 years agox86: sends the EOI earlier in the IRQ path
Barret Rhoden [Sun, 11 Nov 2012 08:58:44 +0000 (00:58 -0800)]
x86: sends the EOI earlier in the IRQ path

This makes it easier to merge all the architecture's KMSG code.  Also,
Linux does this, at least it looks like they do based on a cursory
glance a few months ago.

6 years agoGhetto benchmark test
Barret Rhoden [Wed, 21 Nov 2012 02:50:02 +0000 (18:50 -0800)]
Ghetto benchmark test

Juan had a problem with code similar to this.  If you don't do
res += whatever
and juse do
res = whatever
(his example code), then you could get varying results based on what
else you put in the loop.  Specifically, if you do some extra stuff like
a read_tsc() and track the number of loop iterations, then the critical
path of the inner loop is actually shorter than without, leading to a
10-20% performance difference.

6 years agopthread_test() and supporting changes
Barret Rhoden [Mon, 19 Nov 2012 23:56:20 +0000 (15:56 -0800)]
pthread_test() and supporting changes

The ugly bit is that the pthread 2LS wants to adjust the number of
vcores, but for testing, we want a fixed amount.  Hence the function to
toggle the bool.  We can sort out something better once we have a real
2LS.

7 years agoKernel message nested function scoping
Barret Rhoden [Fri, 9 Nov 2012 16:09:47 +0000 (08:09 -0800)]
Kernel message nested function scoping

Sometimes when we define kernel message functions inside another
function, the compiler will put function's code on the stack.

This happens now with the __test_cv functions in testing.c.  It doesn't
seem to do it for others, and as far as I can tell, it will do so when
the function references stack variables.  Makes sense, since
stack-relative addresses are the only way to know where the variables
are.

Anyway, I don't know if the compiler will ever put those functions on
the stack for other reasons.  Since it's probably a bad idea to refer to
items after their scope disappears, move the KMSG handlers outside the
scope of their caller.  If you don't, be careful.

It's tempting to use some form of synchronization to keep the
encapsulating function alive til the handlers complete, say with a flag
variable or something (which we tend to do anyways).  However, there's
still a slight race after the handler function signals and before that
code returns/pops its stack frame.

7 years agoRemoves SPARC ifdefs from blockdev code
Barret Rhoden [Fri, 9 Nov 2012 15:14:17 +0000 (07:14 -0800)]
Removes SPARC ifdefs from blockdev code

If SPARC or any other arch can't kthread, then many other things won't
work and that needs to be fixed ASAP.

7 years agoChanges semaphore API
Barret Rhoden [Fri, 9 Nov 2012 15:10:20 +0000 (07:10 -0800)]
Changes semaphore API

There now is an irqsave API, same as CVs.  All semaphore users need to
change and use irqsave if they will be called from irq context.  This
also renames sleep_on() to sem_down().  There's no awesome way to name
it, other than to know what it means to down a semaphore.

Also, we now only disable irqs when blocking a kthread for the smallest
amount of time (unless its irqsave): when we need to atomically sleep
and change to a new thread (stack).

7 years agoFixes irqsave issue with CVs
Barret Rhoden [Mon, 5 Nov 2012 21:22:34 +0000 (13:22 -0800)]
Fixes irqsave issue with CVs

Using spinlock_irqsave like that isn't sufficient.  The spinlock_irqsave
really only works across a single lock/unlock pair (it saves the irq
state in the lock).  When we unlock, we potentially reenable irqs.

During the while loop (which enforces ordering), we basically are
holding a sort of lock.  Signallers run from irq context could interrupt
us, deadlocking the system.

Instead, we just have the caller of the CV tell us if we want IRQs off
or not.  Pay attention to the note in trap.c.

In the future, I might rewrite the kthread code to use CVs instead of
semaphores, which would get rid of the while loop/ordering.  Regardless,
I still prefer having the cv_*_irqsave() functions.

7 years agoFixes sys_waitpid() to handle concurrent waiters
Barret Rhoden [Mon, 5 Nov 2012 16:11:07 +0000 (08:11 -0800)]
Fixes sys_waitpid() to handle concurrent waiters

As mentioned before, we could have concurrent syscalls from the parent
waiting on a child or any child.  The issues were trying to reap a child
that has been already reaped (by a -1 or a particular wait call), and
having the children list get emptied while sleeping (for waitpid(-1)).
Additionally, we had to be careful about syscalls blocking and never
getting a wakeup signal.

None of our apps do multiple waiting syscalls, so I haven't tested the
corner cases.

This all is an example of complications arising with concurrent syscalls in
code that would be easier with just synchronous SCPs.  Not a
deal-breaker, just a minor pain.

7 years agosys_waitpid() improvements (XCC)
Barret Rhoden [Tue, 30 Oct 2012 17:10:59 +0000 (10:10 -0700)]
sys_waitpid() improvements (XCC)

Cleans up the glibc fork/wait mess by supporting waitpid(-1).  This will
allow shells (busybox/ash) to do some decent job control with
backgrounding tasks.  Previously, we'd wait on our children in order,
instead of waiting on any available child.

This does not handle concurrent wait calls from the parent (even SCPs
could do async calls).  I'm working on that, and will have it in another
commit to serve as an example of the pain caused by concurrent process
management syscalls (whether due to async syscalls by an SCP or parallel
calls from an MCP).

Rebuild glibc.

7 years agoCondition variables
Barret Rhoden [Thu, 25 Oct 2012 21:08:13 +0000 (14:08 -0700)]
Condition variables

Built with semaphores.  This is notoriously tricky, and I might not have
done it correctly.

See http://research.microsoft.com/pubs/64242/implementingcvs.pdf for a
discussion of some of the issues.

I get around it by peaking in the semaphore and using its count as a
'lock' to enforce an ordering on waiters so that the order in which you
hit the CV is the order that you hit the internal sem.  And since it's
the sem's count, we can atomically sleep on the sem and 'release' that
'lock'.

7 years agoSemaphore upping done with irqsave
Barret Rhoden [Thu, 25 Oct 2012 19:39:27 +0000 (12:39 -0700)]
Semaphore upping done with irqsave

So this isn't actually necessary, but might help us in the future.

If the semaphore is never locked and then potentially interrupted, then
we're okay.  sleep_on() disables IRQs.  If there is only one IRQ handler
that ups a particular sem, then we also aren't in danger of deadlocking.

Anyway, __up_sem() is being used in a bunch of places, and might be used
somewhere in the future that could have an issue with irqsaving.  Like
if process context code was calling __up_sem() *and* there was one IRQ
handler calling __up_sem(), then we could deadlock.

7 years agokthread_yield()
Barret Rhoden [Thu, 25 Oct 2012 19:34:11 +0000 (12:34 -0700)]
kthread_yield()

Caller is suspended in a kthread, and will get woken up via RKM to the
calling core.  In essence, it pauses the kthread and allows other RKMs
to run.

If the ksched does anything fancy, we could do other things, like send
the kthread to another core.

7 years agoFixes RESET_STACKS
Barret Rhoden [Thu, 25 Oct 2012 19:31:03 +0000 (12:31 -0700)]
Fixes RESET_STACKS

Need to not inline __smp_idle(), o/w the set_stack_pointer mucks with
things (specifically, it was mucking with the first word of the previous
page, which was often kthread poison).

7 years agoParent processes track children
Barret Rhoden [Mon, 22 Oct 2012 22:43:48 +0000 (15:43 -0700)]
Parent processes track children

Instead of relying on just the child having the ppid number.  Plus,
there's a little more info in the monitor commands (ps, procinfo), and
trywait was cleaned up a bit.

If the comment about why children don't keep pointers to their parents
doesn't make sense, look over the kref Documentation and think about how
we could ever safely disown a child (like if a parent terminates first).

7 years agoPOSIX signal sending / reception (XCC)
Barret Rhoden [Sat, 20 Oct 2012 00:23:24 +0000 (17:23 -0700)]
POSIX signal sending / reception (XCC)

Adds kernel support for basic POSIX inter-process signals.  We just
multiplex signals through a new Event type.  There's a kernel helper to
send signals, if you want.

Uthread code registers an ev_q for the signals, and right now just has a
dummy handler.  We'll need to hook this in to glibc for support of all
the usual signal-related functions.

Also, grab the new busybox config - it supports kill.

Rebuild your cross compiler/kernel headers and anything that linked
against parlib (like busybox).

7 years agoFixes potential race with SCPs blocking (XCC)
Barret Rhoden [Fri, 19 Oct 2012 23:00:05 +0000 (16:00 -0700)]
Fixes potential race with SCPs blocking (XCC)

If we ever received an event/notif after registering the ev_q and before
yielding, that event would cause us to clear notif_pending.  This would
cause us to sleep permanently in yield, since we already both received
the 'syscall done' event and marked its reception.

If you want to write similar code, the important thing was that we need
notifs disabled before we check the syscall's SC_DONE.

7 years agoRemoves EBADPROC
Barret Rhoden [Thu, 18 Oct 2012 22:22:22 +0000 (15:22 -0700)]
Removes EBADPROC

Which is really ESRCH.  No real need to reinstall your kernel headers,
unless you happen to try to compile program that was using that error
number...

7 years agoFixes struct proc initialization
Barret Rhoden [Thu, 18 Oct 2012 22:10:53 +0000 (15:10 -0700)]
Fixes struct proc initialization

We weren't initialized the ksched_data.  Instead of adding that, or
using Ivy, we'll just memset the whole thing to 0, and then selectively
set whatever needs set (sometimes to 0 to be explicit).

7 years agoAdds proc-internals documentation
Barret Rhoden [Tue, 16 Oct 2012 21:38:12 +0000 (14:38 -0700)]
Adds proc-internals documentation

On the recent patches related to proc mgmt KMSGs and related issues.

7 years agoNo longer disables irqs when mucking with pcpui
Barret Rhoden [Mon, 15 Oct 2012 21:16:51 +0000 (14:16 -0700)]
No longer disables irqs when mucking with pcpui

For things like cur_proc, owning_{proc,vcoreid}, and cur_tf, we don't
disable interrupts when mucking with them in proc code.  We used to need
this when proc mgmt KMSGs were immediate.  So long as we continue to not
muck with that state from IRQ handlers or IMMED KMSGs, we're okay.

7 years agoChanges proc mgmt kmsgs back to ROUTINE
Barret Rhoden [Fri, 12 Oct 2012 02:17:07 +0000 (19:17 -0700)]
Changes proc mgmt kmsgs back to ROUTINE

They all still return, and all still work on cur_tf, but they don't take
effect immediately.  We used to need this since the ksched used to wait
in __map_vcore().  Now that we wait for a __preempt to finish in KMSG
handlers (e.g., __startcore), we don't need IMMEDIATE messages.

This change also makes it so that when we are in fault or trap handlers
(including syscalls), that the cur_tf hasn't been saved and possibly
restarted somewhere else *yet*.  Though there may be a message waiting
to do the __preempt.  Syscalls that try to muck with the vcore map need
to be careful, but all calls will at least know what VC they are on and
what the cur_tf was at the time of the exception.

7 years agoVcore versioning for __preempt / __startcore (XCC)
Barret Rhoden [Fri, 12 Oct 2012 01:50:13 +0000 (18:50 -0700)]
Vcore versioning for __preempt / __startcore (XCC)

Replaces preempt_served with a better mechanism to detect preemptions.
Instead of spinning while holding the proc_lock (in __map_vcore()), we
spin in the __startcore (or __set_curtf()) handlers from KMSG context.
This sets up a happens-before ordering where we wait to make sure a
preempt happened before starting a core.

The old code can use the vcoremap, but one of the issues is that
syscalls can run for a vcore/cur_tf after that vcore has been unmapped
and then remapped again.  Simply detecting this isn't enough btw, since
it can be a real pain to deal with (imagine a page fault, or a trap of
some sort).  Better documentation to follow.

Reinstall your kernel headers and rebuild your parlib/userspace.

7 years agoFixes sys_change_to memory clobber
Barret Rhoden [Thu, 11 Oct 2012 00:32:18 +0000 (17:32 -0700)]
Fixes sys_change_to memory clobber

This was previously fixed in the kernel in 67e1cce, and then screwed up
recently in d9513a4.

Fixing it in the kernel is a bad way to go, so this fixes it in
userspace.  The core issue is userspace asks the kernel to do something
to basically 'free' memory (reset the VC ctx to the top of stack), and
that memory is being used by the kernel to report the syscall.  It's
somewhat equivalent to mmapping a page, putting a struct syscall on it,
then using that to request munmapping that page, and then being
surprised when something bad happens to you (we actually don't handle
this well yet).

7 years agoAdded gccgo support for akaros
Kevin Klues [Mon, 15 Oct 2012 22:11:17 +0000 (15:11 -0700)]
Added gccgo support for akaros

As of now, the gccgo compiler builds and links, but probably doesn't do
anything useful in terms of getting go programs to actually compile and
run.  This is basically the initial commit with all of the proper
infrastructure in place so we can add full support later on.

7 years agoFixes potential livelock in preemption handling
Barret Rhoden [Fri, 5 Oct 2012 23:50:56 +0000 (16:50 -0700)]
Fixes potential livelock in preemption handling

Adds a method to handle one message at a time, needed for the early loop
in uthread_vcore_entry().  Check the new and improved Documentation
about preemption recovery to find out why!

7 years agoSeparate handler for EV_CHECK_MSGS
Barret Rhoden [Fri, 5 Oct 2012 00:26:05 +0000 (17:26 -0700)]
Separate handler for EV_CHECK_MSGS

Instead of trying a full preemption recovery.  We weren't even doing
anything before this patch, since we never registered any handler.  Both
the preemption handler and the indir handler work.

7 years agocan_rcv_msg is now a VC flag (XCC)
Barret Rhoden [Fri, 5 Oct 2012 00:09:31 +0000 (17:09 -0700)]
can_rcv_msg is now a VC flag (XCC)

Solves a race with can_rcv_msg between a preemption handler and the
kernel when that vcore starts back up.  Though the kernel would
eventually have found a message recipient.  Anyway, it's better now.

Rebuild userspace libraries / apps (anything touching vcpd).

7 years agoFixes bug in generic_dir_read()
Barret Rhoden [Thu, 4 Oct 2012 23:26:32 +0000 (16:26 -0700)]
Fixes bug in generic_dir_read()

And cleans up error handling in elf.c.  This bug showed up when trying
to load "/" as an elf (telling ash "./", which thought it was a binary).
generic_dir_read() would clobber the stack of load_one_elf() due to bad
boundary checks in its for loop.

Also, makes elf failures easier to debug, and tries to catch more issues
based on read()'s retvals.

7 years agoFixes dumb bug in clear_owning_proc()
Barret Rhoden [Thu, 4 Oct 2012 21:31:46 +0000 (14:31 -0700)]
Fixes dumb bug in clear_owning_proc()

7 years agoFixes change_to_vcore failure case
Barret Rhoden [Wed, 3 Oct 2012 01:00:11 +0000 (18:00 -0700)]
Fixes change_to_vcore failure case

sys_change_vcore() could fail for a few reasons.  Previously, userspace
was assuming that if it failed it was because the vcore was already
running.  However, it can fail because the caller is getting preempted.

Changes the syscall to pass back a return value based on the type of
failure.  Userspace now continues to attempt to change until it not
longer is told to try again.

Note that it is not necessary to loop in code like ensure_vcore_runs,
since those functions are already called in busy loops.

7 years agoAdds some event/uthread debugging code
Barret Rhoden [Tue, 2 Oct 2012 00:14:20 +0000 (17:14 -0700)]
Adds some event/uthread debugging code

And a better rassert.  When I have weird low-level bugs, I plan to
include rassert.h instead of using the glibc assert.  Might make it the
default for all of parlib at some point.

7 years agoHelpers to determine vcoreid (XCC)
Barret Rhoden [Thu, 27 Sep 2012 00:14:28 +0000 (17:14 -0700)]
Helpers to determine vcoreid (XCC)

Some helpers, useful in debugging and low-level (glibc) code.

It's actually not possible (currently) for a syscall to know what
vcore submitted the syscall, due to concurrent preemptions.  But given a
pcoreid, you can tell what vcore is running.  We might fix
sys_getvcoreid in the future.  Regardless, the pcoreid version is worth
checking out.

Reinstall your kernel headers.

7 years agoFixes set_tls_desc() bug (XCC)
Barret Rhoden [Wed, 26 Sep 2012 01:44:00 +0000 (18:44 -0700)]
Fixes set_tls_desc() bug (XCC)

set_tls_desc() has historically set __vcoreid within the TLS to whatever
vcoreid it is being loaded on.  This was an ugly leftover from back in
the day.  It is necessary to do this for uthreads that are starting up
on a vcore (so they know which vcore it is), but we *never* want to do
this for vcore contexts.

This surfaced when handling_vc_preempt(), when we changed into a
remote vcore's TLS.  That would clobber their __vcoreid, which would lead
to all sorts of confusion (using the wrong MCS lock qnode, loading other
vcore TLSs instead of your own, telling uthread's the wrong vcoreid,
etc).

You need to rebuild glibc (copy over the edited file before building).

7 years agoFixes bug with uthread migration
Barret Rhoden [Tue, 25 Sep 2012 23:35:17 +0000 (16:35 -0700)]
Fixes bug with uthread migration

We were calling functions in uthread_pause that used TLS.  Instead of
making that illegal, I just cut down the time we're in another vcore's
TLS to a very small, controlled region.

7 years agoFixes bug where syscalls were completed twice
Barret Rhoden [Tue, 25 Sep 2012 23:03:02 +0000 (16:03 -0700)]
Fixes bug where syscalls were completed twice

When proc_yield() failed, the syscall would be completed twice.  When
that vcore was preempted and restarted on another core (due to a
change_to, for instance), after the first completion, the vcore would
return up the stack.  When the second completion hits, the kernel would
clobber a small part of the stack (syscalls are usually on the user
stack), which would have disasterous effects (looked like registers were
getting clobbered).

7 years agoUCQ debug code
Barret Rhoden [Tue, 25 Sep 2012 23:00:56 +0000 (16:00 -0700)]
UCQ debug code

Depending on what you want, you'll probably need to update test_ucq().
As is, you can only run it, then reboot.  It's a little better at
testing chains, and we now have some debug helpers (call with kfunc) to
get a better peak at a ucq.

7 years agoFixes preemption handling bug
Barret Rhoden [Wed, 5 Sep 2012 23:48:58 +0000 (16:48 -0700)]
Fixes preemption handling bug

If a vcore comes up while another vcore is stealing its uthread, it
needs to check for preemptions.  There are a bunch of ways to do this.
The old way was wrong, since it assumed the preempt_ev_q had an actual
mbox, which it wasn't.  Given our current preempt_ev_q style, we want to
check our public mbox for any preempt-msg-spam, which we'd get if we
were the last core around.

Note this might not be ideal - we still have a lot of messages being
sent, and we might be able to cut that down by using a different style.
For now, it fixes the bug.

7 years agoFixes list management bug in the ksched
Barret Rhoden [Wed, 16 May 2012 20:59:14 +0000 (13:59 -0700)]
Fixes list management bug in the ksched

A poorly timed death callback was corrupting lists by removing the dying
proc from the primary list twice.  (If death happened while the dying
proc was being serviced by __run_mcp_ksched()).

Also gets rid of the "it must be on a list, but i don't know which one"
style of list removal.

7 years agoProc code locks before disabling IRQs
Barret Rhoden [Mon, 14 May 2012 22:08:09 +0000 (15:08 -0700)]
Proc code locks before disabling IRQs

While we cannot grab the lock with interrupts off, we *can* disable
after grabbing the lock, but only under certain circumstances.  This is
because we send the kmsgs with the lock held.  Once we hold the lock, we
know no one will send proc mgmt kmsgs except us.  And it is really
important that we don't send any in these functions.  (imagine trying to
do a __preempt, when you send something to your own core and then try to
__map_vcore, and never get the message).

Also note that we must use immediate messages (which we've been doing
for a while now).  If we didn't use immediate kmsgs for __preempt,
someone (for instance) yielding or change_to-ing would spin on the lock
til they got the lock, but would never get the message since the lock
holder was waiting on them to do the __preempt.

Btw, in case it wasn't clear, the lock holder is spinning in
__map_vcore(), which is where we wait on the completion of the __preempt
kmsg.

7 years agoEnsures IRQs are enabled when proc_destroy()ing
Barret Rhoden [Mon, 14 May 2012 22:00:49 +0000 (15:00 -0700)]
Ensures IRQs are enabled when proc_destroy()ing

The main reason is that irqs need to be on when grabbing the proclock.
There are some deadlock scenarios where a __preempt (or even __death)
kmsg is sent with the lock held to a core, but if that core has irqs
disabled, it won't process the message (circular waiting, etc).

While I could make proc_destroy() enable irqs, its really up to the
calling code to do that.  I put in asserts where they shouldn't be
disabled, and otherwise turned them on manually.  This mostly applies to
trap handling code.  Note we can't just turn on IRQs immediately - each
case needs to do it where it is possible (preferably sooner than later),
such as after reading cr2() in x86's PF handler.

7 years agoDebug code to see remote kmsgs
Barret Rhoden [Mon, 14 May 2012 21:55:04 +0000 (14:55 -0700)]
Debug code to see remote kmsgs

Mostly useful for resolving deadlocks - you can see what kmsgs are on
remote cores.  It won't deal with races (though I can build that in if
we want).

The easiest way to use it on x86 is to "trace coretf coreid", since I
built it in the NMI handler.  Or you can kfunc print_kmsgs 0xcoreid
(remember, kfunc deals with hex!).

7 years agoLock ordering and ksched callbacks
Barret Rhoden [Mon, 14 May 2012 20:43:24 +0000 (13:43 -0700)]
Lock ordering and ksched callbacks

For now, there is no ordering between the proc lock and the ksched lock.
This commit revises a bunch of the scheduler callbacks (all clearly
prefixed with __sched).  These CBs can be triggered from lots of places,
specifically any proc code, any event code, and any code that kills a
process (like a PF handler!).

Since these grab locks, we needed to make the ksched let go of its lock
before calling into proc/event code (preempt_core() triggers events,
among other things).

This also moves the proc functions (like destroy) back into proc code,
since we no longer need to lock in the ksched before calling proc code.

We also can get rid of the 'ignore_next_idle'.  For now, we just wait
til the core has been given back in __core_req (no deadlock now, just a
race), instead of knowing it will be idle soon and circumventing the CB.
It's a toss-up between these two solutions.

7 years ago__core_request no longer locks and calls proc code
Barret Rhoden [Thu, 10 May 2012 02:18:26 +0000 (19:18 -0700)]
__core_request no longer locks and calls proc code

Part of a move to make the ksched lock not lock-ordered before the proc
lock.

__core_req needs to be careful about how things change when it unlocks.
for instance, there might be callbacks for cores yielding or procs
dying, or someone might have called provision_core().  I think I've
covered the cases, but it's a bit fragile.

Also note that I'm relying on __core_req being called once at a time
only (specifically, that there are no other preemptors or allocators).
The poke_tracker gives me that.  (That, and that __core_req is only
called from within the poke).

7 years agoMCP ksched doesn't need to hold the lock forever
Barret Rhoden [Wed, 9 May 2012 23:03:15 +0000 (16:03 -0700)]
MCP ksched doesn't need to hold the lock forever

__core_request() can now let go of the ksched lock.  We only have that
lock held in __run_mcp_ksched() when we need to muck with things the
lock explicitly protects: proc list integrity and membership in this
case.

7 years agoPost-and-poke style sync for the ksched
Barret Rhoden [Wed, 9 May 2012 02:45:27 +0000 (19:45 -0700)]
Post-and-poke style sync for the ksched

Might change some of the details of the "poke-style", but I definitely
want at least a generic version of it (and all of its mb()s) to be
kernel-wide.

This is the same style of sync used in vcore_request(), though that one
is built in directly.

Note that we still use the ksched lock within in poke func - all this
commit does is create the poke style and use it to trigger the sched
mcp.  I'll deal with the lock holding shortly.

7 years agoFixes up amt_wanted/amt_granted in __core_request
Barret Rhoden [Sat, 5 May 2012 05:50:18 +0000 (22:50 -0700)]
Fixes up amt_wanted/amt_granted in __core_request

I considered holding the proclock the entire time, and it's actually
safe to do so (we make sure we don't preempt the proc we are trying to
give the core to, which would DL).  But this way, we don't sit on the
lock forever, and only do it when we need to.  Now we're just a bit more
clear about things.  (It wasn't clear before, and was a potential issue
when hunting a brutal bug).

Oh, and this was not fixing up amt_wanted like it thought it was.

7 years agoSpinlock depth checking
Barret Rhoden [Fri, 4 May 2012 22:38:03 +0000 (15:38 -0700)]
Spinlock depth checking

This tracks how many locks we acquired on a pcpu basis.  Before we
kthread/block or anything like that, the number better be 0.  Not only
is it bad for perf, but you could deadlock.

Needed this to hunt down a deadlock bug (asserted in some place where I
thought I had no locks), though it had nothing to do with sleeping.

It only does work when CONFIG_SPINLOCK_DEBUG is on, though you can
always test for it (and you'll get 0).

I didn't compile it for RISCV.  YMMV.

7 years agoFixes some deadlock scenarios
Barret Rhoden [Fri, 4 May 2012 22:09:11 +0000 (15:09 -0700)]
Fixes some deadlock scenarios

Can't send messages with the proclock held unless there is an active
vcore.  O/W, event code may attempt to wake up the proc and/or grab the
proc_lock when it makes sure a message gets through.

There are a variety of other related issues, such as the ksched calling
event code (via proc code) that could call proc_wakeup().

7 years agoKsched allocates provisioned cores
Barret Rhoden [Tue, 1 May 2012 22:47:34 +0000 (15:47 -0700)]
Ksched allocates provisioned cores

When servicing a proc (via the ksched's linear scan of all MCPs or via a
poke_ksched()), the ksched will preempt cores provisioned to a process
that are allocated to another process.

We also do a somewhat-ghetto trick when the ksched is attempting to
preempt a core, but is racing with that proc yielding the core.  We
short-circuit put_idle, since the ksched noticed the core is not
allocated before proc code told the ksched.

7 years agoChanges idlecoremap to a list
Barret Rhoden [Tue, 1 May 2012 19:56:22 +0000 (12:56 -0700)]
Changes idlecoremap to a list

Other than cleaning things up (the map was pretty nasty), this allows us
to allocate specific cores and pull them off the idlelist without having
to scan.

7 years agoBetter ksched helpers for pcoreid <-> sched_pcore
Barret Rhoden [Tue, 1 May 2012 19:17:06 +0000 (12:17 -0700)]
Better ksched helpers for pcoreid <-> sched_pcore

Also cleans up some debug/printing code (lists procs as pid (pointer),
instead of pointer (pid)).

7 years agoRemoves option for a dedicated monitor core
Barret Rhoden [Tue, 1 May 2012 18:34:39 +0000 (11:34 -0700)]
Removes option for a dedicated monitor core

This was an old option that only made sense when we couldn't get to the
monitor by interrupt.

7 years agoRenames TAILQ_ENTRY in sched_pcore
Barret Rhoden [Tue, 1 May 2012 18:29:17 +0000 (11:29 -0700)]
Renames TAILQ_ENTRY in sched_pcore

In anticipation of another next/link

7 years agoCleans up proc_preempt_core()
Barret Rhoden [Tue, 1 May 2012 18:16:28 +0000 (11:16 -0700)]
Cleans up proc_preempt_core()

It's now the caller's responsibility to do something with the idle core.

7 years agoproc_yield() and change_to_vcore() use unmapping
Barret Rhoden [Mon, 30 Apr 2012 22:13:27 +0000 (15:13 -0700)]
proc_yield() and change_to_vcore() use unmapping

As their signal, instead of preempt_served.  They were checking the
vcoremap anyway, but for different reasons, and now it's clear what they
are doing.

7 years agoproc_get_vcoreid() usage clarification
Barret Rhoden [Mon, 30 Apr 2012 20:57:36 +0000 (13:57 -0700)]
proc_get_vcoreid() usage clarification

Don't use it to ask about remote cores.  You could, but you'd be getting
potentially old info, so I just removed the option.  This makes the
systracing code a little slower, but things are a little safer for new
code.

7 years agoProc code unmaps vcores when taking cores
Barret Rhoden [Mon, 30 Apr 2012 20:48:29 +0000 (13:48 -0700)]
Proc code unmaps vcores when taking cores

Instead of leaving the mapping up for the __preempt or __death code to
deal with.  That code now uses the pcpui var.  Check out the doc changes
for more info.

7 years agoTracks proc's vcoreids in pcpu info
Barret Rhoden [Mon, 30 Apr 2012 18:06:38 +0000 (11:06 -0700)]
Tracks proc's vcoreids in pcpu info

So k_msgs and other functions running on MCP cores do not need to look
at the pcoremap.

7 years ago__startcore now takes the vcoreid as a parameter
Barret Rhoden [Mon, 30 Apr 2012 17:43:04 +0000 (10:43 -0700)]
__startcore now takes the vcoreid as a parameter

Instead of reading from the vcore/pcoremap to determine the vcoreid.
This is part of a series of patches that will remove accesses of the
vcoremap from unlocked code.  This will clean up a few nasty scenarios.

7 years agoKsched functions to provision cores
Barret Rhoden [Thu, 26 Apr 2012 20:48:01 +0000 (13:48 -0700)]
Ksched functions to provision cores

You can provision cores, and this code will track where each core is
provisioned and/or allocated to.  The scheduler does nothing with this
info yet.

Also some CG/LL changes - notably we don't reserve a core for the NIC
anymore, and if you use any of the other antiquated core reservation
CONFIGs, something will break when you provision that core.  That'll get
sorted out eventually.

7 years agoput_idle_cores() takes a proc * and locking strat
Barret Rhoden [Wed, 25 Apr 2012 23:23:52 +0000 (16:23 -0700)]
put_idle_cores() takes a proc * and locking strat

And is safer about locking (will be needed shortly).  The diff btw the
internal and external versions is the holding of the sched lock.

Now, the sched lock is protecting the sched lists, the 'idlecoremap',
and will soon protect the provisioning lists in proc->ksched_data.

7 years agoCleans up TLS access macros (XCC)
Barret Rhoden [Wed, 5 Sep 2012 20:58:58 +0000 (13:58 -0700)]
Cleans up TLS access macros (XCC)

Documents and cleans up the TLS access macros.  A bunch of the comments
were lost a few commits back.

Since I was changing things, I fixed up the whitespace and formatting
too.  If you want to review this, ignore whitespace.

You need to rebuild glibc, though not because of this patch.  Some of
the previous ones changed a few things (esp 716debe).  I needed to
completely rebuild glibc (delete glibc-XXX directory, the i686
files/directories, etc).

7 years agomake risc-v front-end syscalls asynchronous
Andrew Waterman [Fri, 18 May 2012 23:53:50 +0000 (16:53 -0700)]
make risc-v front-end syscalls asynchronous

also add DEMO mode, where the system waits for
ELFs to be sent over stdin and executes them

7 years agofix risc-v fpu emulation bugs
Andrew Waterman [Fri, 18 May 2012 23:53:34 +0000 (16:53 -0700)]
fix risc-v fpu emulation bugs

7 years agoimplement stdout with cputbuf instead of printk
Andrew Waterman [Fri, 18 May 2012 23:51:38 +0000 (16:51 -0700)]
implement stdout with cputbuf instead of printk

This improves stdout bandwidth.  (Yes, it matters to us :-))

7 years agofix risc-v compiler bug for sin/cos/exp/...
Andrew Waterman [Tue, 29 May 2012 04:59:51 +0000 (21:59 -0700)]
fix risc-v compiler bug for sin/cos/exp/...

7 years agofor RISC-V, emulate missing fdiv/fsqrt instructions
Andrew Waterman [Tue, 29 May 2012 04:36:00 +0000 (21:36 -0700)]
for RISC-V, emulate missing fdiv/fsqrt instructions

7 years agofix more risc-v compiler bugs
Andrew Waterman [Wed, 23 May 2012 17:16:14 +0000 (10:16 -0700)]
fix more risc-v compiler bugs

7 years agofix headers barfing when used in c++ programs
Andrew Waterman [Wed, 23 May 2012 17:15:49 +0000 (10:15 -0700)]
fix headers barfing when used in c++ programs

7 years agoUpdate uthread_init to use uthread_set_tls_var macro
Kevin Klues [Thu, 17 May 2012 18:45:23 +0000 (11:45 -0700)]
Update uthread_init to use uthread_set_tls_var macro

As a side effect, this also removes the reliance on
uthread_init needing to assert that it is called from
vcore context.

7 years agoAdded #include for sys/vcore-tls.h for x86
Kevin Klues [Thu, 17 May 2012 16:10:37 +0000 (09:10 -0700)]
Added #include for sys/vcore-tls.h for x86

7 years agoimprove risc-v console
Andrew Waterman [Thu, 17 May 2012 04:12:52 +0000 (21:12 -0700)]
improve risc-v console

we now explicitly read the keyboard in non-canonical mode.

7 years agofix a riscv gcc bug
Andrew Waterman [Thu, 17 May 2012 03:12:48 +0000 (20:12 -0700)]
fix a riscv gcc bug

7 years agoRISCV uses the no-CAS version of MCS-PDR locks
Andrew Waterman [Wed, 16 May 2012 00:40:51 +0000 (17:40 -0700)]
RISCV uses the no-CAS version of MCS-PDR locks

These ones don't know how to figure out what vcore in particular needs to run,
so they make all (preempted) vcores run.  It'll eventually work out.

Also, the reason we needed to do this was because RISCV's CAS is busted and
does not allow independent access of the variable.  All accesses to (current)
RISCV CAS variables needs to be through CAS.

Note this means that registering event queues for blocking syscalls is busted.

7 years agohandle TLS mostly in glibc, not parlib
Andrew Waterman [Tue, 15 May 2012 12:11:24 +0000 (05:11 -0700)]
handle TLS mostly in glibc, not parlib

7 years agorisc-v bugfix potpourri
Andrew Waterman [Tue, 15 May 2012 12:10:47 +0000 (05:10 -0700)]
risc-v bugfix potpourri