akaros.git
7 years agoproc_destroy() no longer requires edible refs
Barret Rhoden [Thu, 29 Sep 2011 21:30:38 +0000 (14:30 -0700)]
proc_destroy() no longer requires edible refs

proc_destroy() will return, though it does require handling an IMMEDIATE
kmsg (which PRKM currently does, or you can enable interrupts at some
point) before the kernel returns to userspace (in the event of
proc_destroy() being called on the current_tf).

Note that all return paths need to check interrupts (and RKMs) at some
point.

7 years agoRemoves __proc_kmsg_pending()
Barret Rhoden [Thu, 29 Sep 2011 20:12:01 +0000 (13:12 -0700)]
Removes __proc_kmsg_pending()

Since proc management kmsgs return and are IMMEDIATE, we no longer need
the painful logic of determining that the kernel needs to clean up in
anticipating of a 'stack killing' kmsg.

This means schedule() can run on a core, preempt the _M's vcore running
there, and give out both that vcore and the pcore without worrying about
its own code getting interrupted.

7 years agoProcess mgmt kmsgs are now IMMEDIATE
Barret Rhoden [Thu, 29 Sep 2011 01:37:27 +0000 (18:37 -0700)]
Process mgmt kmsgs are now IMMEDIATE

Instead of ROUTINE.  This means that __startcore, __notify, __preempt,
and __death now are received whenever interrupts are enabled, instead of
only when we PRKM.  This means we no longer need to go out of our way to
get these messages, which will allow me to clean up some proc mgmt code
in future commits.

Note that __launch_kthread() is still ROUTINE, since it does not return.

7 years agoProtects cur_tf by disabling interrupts
Barret Rhoden [Wed, 28 Sep 2011 20:58:06 +0000 (13:58 -0700)]
Protects cur_tf by disabling interrupts

Disable interrupts to keep cur_tf or its contents from changing out from
under you.  This doesn't happen yet, since all kmsgs that change cur_tf
are still routine.

proc_yield() needs to be careful due to concurrent notifications.
proc_yield() is a lot like the other blocks of code that adjust a
process's state on a core (__startcore, __preempt, etc): it should be
run with interrupts disabled to avoid any interleavings.

The changes to _S code (fork/exec) are there just in case we muck with
cur_tf in the future.

7 years agoProc kmsgs now make their changes to cur_tf
Barret Rhoden [Wed, 28 Sep 2011 00:57:47 +0000 (17:57 -0700)]
Proc kmsgs now make their changes to cur_tf

Previously, when a process management kernel message came in, it's
effects would be felt immediately.  A new TF would be popped, etc.  Now,
all of these messages work on the cur_tf, which is the context that will
run when the kernel is done and either idles or reaches a place it can
run a process (like a PRKM site) (which is where we call
try_run_proc()).

Put another way, instead of actually running the context, we just set up
to run it later.  We can then handle other messages (like a __preempt),
which will just change the cur_tf to do what we want when we attempt to
run them (in that case, it will be to do nothing, since __preempt sets
cur_tf to 0).

Also, __startcore and __notify now return.  __launch_kthread still does
not.

7 years agoset_current_tf() no longer sets the local *tf var
Barret Rhoden [Wed, 28 Sep 2011 00:44:24 +0000 (17:44 -0700)]
set_current_tf() no longer sets the local *tf var

Meaning that we only copy out the *tf and set cur_tf, but do not change
tf in the calling function.  The contents are the same, but if something
happens that changes cur_tf's contents, you're still using the same one
you came in on (this will matter for a future commit).

The old style had a bug too.  If a kthread migrated, when it returned up
its stack and it looked at *tf, it would point to the cur_tf of possibly
another core (which is not what we want).  We want to point to the
original TF we came in on, so we can decide if we should return to the
kernel or not (and if we do, we just pop that TF).

Sparc and RISCV probably need a little work.  I put warns in there to
catch IRQs being enabled.  set_current_tf() probably needs to be called
more often too (like when handling other traps).

7 years agox86 interrupts are disabled til cur_tf is set
Barret Rhoden [Tue, 27 Sep 2011 21:27:36 +0000 (14:27 -0700)]
x86 interrupts are disabled til cur_tf is set

Whenever we're in the kernel with interrupts enabled, if there is a
process that is running (or should be running) on the core, current and
cur_tf should both be set.  On the first time into the kernel (syscall,
trap, etc) from userspace, cur_tf needs to get set.

Also remember that a 0'd cur_tf means that we should no longer run a
context (which happens after a kthread returns from blocking if the
process is no longer present).  In those situations, it is still okay to
have current set.  That is just which process's context we have loaded.

7 years ago__preempt and __death now return
Barret Rhoden [Tue, 27 Sep 2011 00:05:48 +0000 (17:05 -0700)]
__preempt and __death now return

They had been 'stack-smashing' KMSGs, which forced them to be routine
and made it hard to receive them from certain fictional contexts (such
as schedule() trying to preempt the core it runs on from the process
running there.).

7 years agox86 kernel messages go through irq_handler()
Barret Rhoden [Mon, 26 Sep 2011 23:36:18 +0000 (16:36 -0700)]
x86 kernel messages go through irq_handler()

Previously, __kernel_message() was getting called directly from the
assembly routines.  Now, it goes through irq_handler() like all other
traps.  While it is slightly slower, it will go through the same path,
including proc_restartcore() on the way back out.

7 years agoResolves race with __unmap and __map_vcore()
Barret Rhoden [Mon, 26 Sep 2011 20:49:06 +0000 (13:49 -0700)]
Resolves race with __unmap and __map_vcore()

When you send a __preempt message (or __death), the unmapping happens on
the destination core.  If you were to try and give out the vcore
immediately, the old mapping would still be there.  This is a problem
that came about when we switch to using vcore lists.

Now we'll spin til the remote core unmaps.  This means that we can't
have scheduler code (or whatever) try to preempt its current pcore's
vcore and then try to give out that same vcore somewhere else without
take the stack-smashing __preempt message.  No one does this yet, since
our scheduler() only runs on LL cores.

7 years ago_S processes properly map/unmap vcore 0
Barret Rhoden [Mon, 26 Sep 2011 20:32:01 +0000 (13:32 -0700)]
_S processes properly map/unmap vcore 0

To make __death easier, vcore 0 is mapped to whatever pcore the process
is running on in _S.  We were a bit lazy about unmapping it.

7 years agoCleaned up memory barrier usage (XCC)
Barret Rhoden [Sun, 25 Sep 2011 23:16:34 +0000 (16:16 -0700)]
Cleaned up memory barrier usage (XCC)

Cleaned up the use of memory barriers in our shared memory
synchronization code (event stuff, locking stuff, etc).  Check out the
documentation if you plan to write any concurrent, shared memory code
that doesn't use locking.

7 years agoFixes disable_kevent()
Barret Rhoden [Tue, 20 Sep 2011 21:50:14 +0000 (14:50 -0700)]
Fixes disable_kevent()

Need to be more careful with deregistering for events (don't free the
ev_q if it is possible the kernel is still sending messages).

No one uses it yet (or ever), so it's not a big deal.

7 years agoProcesses can yield the entire process
Barret Rhoden [Sun, 18 Sep 2011 02:44:40 +0000 (19:44 -0700)]
Processes can yield the entire process

When yielding your last vcore, you'll now transition to WAITING, and be
woken up when an event comes in.  If you ever want to wake back up,
you'll need to have at least one ev_q marked FALLBACK/INDIR, and have
that ev_q trigger.

We don't support yielding just to be nice.  If you yield, you need an
event to wake you.  Otherwise, just do your work.

This also changes the ksched to be able to handle a RUNNABLE_M, albeit
not in a perfect manner.

7 years agoManager change: Hit Shift-G to get to the monitor
Barret Rhoden [Sun, 18 Sep 2011 02:36:35 +0000 (19:36 -0700)]
Manager change: Hit Shift-G to get to the monitor

For now, the manager will just spin looking for work.  Interrupt it with
a shift-g to get into the monitor.  Believe it or not, this is an
improvement over the old style, though it ideally wouldn't need to spin
looking for work either.

7 years agopthread_join() no longer spins
Barret Rhoden [Sun, 18 Sep 2011 01:29:35 +0000 (18:29 -0700)]
pthread_join() no longer spins

It'll now wait on the join_target, which will wake it up when it exits
(depending on how the atomic_swap race went).

7 years agoev_q option VCORE_MUST_RUN (XCC)
Barret Rhoden [Sat, 17 Sep 2011 00:59:44 +0000 (17:59 -0700)]
ev_q option VCORE_MUST_RUN (XCC)

Some event queues need to have their alerts sent to a vcore that will
definitely run (as of the time alert_vcore() was called), and not just a
can_rcv_msg.  The one (and probably only) example of this is the
preempt_msg ev_q.  Simply put, you can't send the preempt message about
a given vcore to that vcore, which could happen without this option.

Note that the vcore that receives this message can be yielding or
getting preempted or whatever - so long as it wasn't the vcore that
was preempted (and thus generated the preempt message) (unless it will
be forced to run in the ultimate_fallback area).

Even if you want to just poll your preeempt ev_q (and not want an
INDIR), you still need the MUST_RUN flag to make sure the IPI gets
there.  If you don't want an IPI either, you'll have issues with locking
in uthread context and with preemption response latency.

7 years agoAllow ev_qs to not have INDIR throttling (XCC)
Barret Rhoden [Fri, 16 Sep 2011 23:14:43 +0000 (16:14 -0700)]
Allow ev_qs to not have INDIR throttling (XCC)

As a reminder, ev_qs normally will only have one INDIR event sent at a
time (roughly), and future INDIRs/IPIs (alerts) won't be sent until the
main ev_q has been tended to.  This patch allows ev_qs to opt out.

The only use for this I forsee is the preemption ev_q, since the
original INDIR might be sent to a preempted vcore.

7 years agoBreaks up the proc_lock to use the mm_lock
Barret Rhoden [Fri, 16 Sep 2011 23:01:02 +0000 (16:01 -0700)]
Breaks up the proc_lock to use the mm_lock

While this has been needed for a long time, it now is critical due to
event code holding the proc_lock and then posting an INDIR (which may
mmap()).  It's a fairly rare condition (which I didn't get yet), but it
will deadlock.

As it is now, we're okay, so long as our mmap() call doesn't try a
tlbshootdown (which needs the proclock for now).

7 years agoFixes event FALLBACK code
Barret Rhoden [Fri, 16 Sep 2011 00:10:03 +0000 (17:10 -0700)]
Fixes event FALLBACK code

Previously, we had situations where the kernel couldn't find a core that
can_rcv_msg, and the code couldn't handle going into the PROC_WAITING
state.  It could handle going down to one core, but it couldn't handle
process state.

This new version of alert_core() can handle single cores yielding, the
entire process yielding, bulk preemption, single core preemption, and
anything else I can think of.  It does this without locking in the
common case, which would be a scalability problem.  Arguably, when we
need to FALLBACK, all events will pick the same online vcore (first on
the list), and hammer the same VCPD UCQ, but it won't be while holding a
massive lock.

Note that we could have moved __proc_wakeup() from alert_vcore() to
send_event().  It won't hurt to do that, other than to give you the fall
sense of security that a process will always be able to yield without
missing a wake up.  You need to want an INDIR/IPI and want FALLBACK
(which is rapidly becoming the default) to be guaranteed to wake up.

There are a couple other issues that need to be sorted before this can
be used for preemption messages.  Stay tuned!

7 years agoProc state work: WAITING helpers and is_mcp helper
Barret Rhoden [Fri, 16 Sep 2011 00:06:16 +0000 (17:06 -0700)]
Proc state work: WAITING helpers and is_mcp helper

The __proc_wakeup() function can be called whether the process is
WAITING or not - it doesn't particularly care.

Instead of having multiple WAITING states, I'm going with the is_mcp
bool.  This simplifies event code and other places that don't care about
the _M nature of the process.  We'll see if this is a good idea or not.
I might slim down the other states as well, though those seem to work
well with the switch statements.

7 years agoKmsg debug routine
Barret Rhoden [Thu, 15 Sep 2011 00:37:18 +0000 (17:37 -0700)]
Kmsg debug routine

I used this to help with a brutal bug a couple weeks ago (c281e8419974).
Call it with kfunc, or build it in to the monitor if you want, etc.

7 years agoproc_yield() will return if you have an event
Barret Rhoden [Wed, 14 Sep 2011 01:49:11 +0000 (18:49 -0700)]
proc_yield() will return if you have an event

INDIRs will now set notif_pending, whose meaning changes slightly to be
"check your shit".  It's actually always been that, but that was before
we split up INDIRs and IPIs.  Without this, we could miss INDIRs while
trying to leave vcore context.

The intuition here is that processes should not leave vcore context
while notif_pending is set.  There are two ways out, one of which has
been sorted for a while: pop_ros_tf() (note the other uses of
clear_notif_pending()).  The other way is via proc_yield(), and the
kernel will help if we lose those races (racing with send_event()).

When yielding, if we lost the race we bail out.  This is a little
different than the usages of clear_notif_pending() in u/p/uthread.c.  In
those cases, we'll go ahead and run the thread, and the events don't get
a chance to change the mind of the 2LS.  (We can change this in the
future).  When vcore_yield() fails, we go back into the main 2LS loop
(in pthread.c).

Note some of this stuff will be more useful in future patches.  The
details of FALLBACK will change shortly.

7 years agoCleans up __proc_give and _take code
Barret Rhoden [Wed, 14 Sep 2011 00:01:02 +0000 (17:01 -0700)]
Cleans up __proc_give and _take code

It's been ghetto for far too long now.  There's also a slight change in
behavior: on the grant side, num_cpus gets updated before handing out
the vcores.  I prefer it this way, and it doesn't really matter: the
kernel shouldn't expect things to line up while the lock is held, and
userspace shouldn't trust num_vcores/the vcoremap while the seq_ctr is
set.

7 years agoVcore management uses the lists
Barret Rhoden [Tue, 13 Sep 2011 22:36:34 +0000 (15:36 -0700)]
Vcore management uses the lists

Vastly cleans up vcore allocation/discovery/management.  Doesn't use the
bulk_preempt list for the preempt_all yet.  Those will need a bit of
work anyways.

7 years agoVcore lists now track vcore statuses
Barret Rhoden [Tue, 13 Sep 2011 20:39:26 +0000 (13:39 -0700)]
Vcore lists now track vcore statuses

We don't use the lists yet, they just track the state of vcores as they
are granted and taken.

We don't use the bulk preempt list at all yet either.

7 years agoCleans up fork/exec's procinfo/data handling
Barret Rhoden [Tue, 13 Sep 2011 18:35:06 +0000 (11:35 -0700)]
Cleans up fork/exec's procinfo/data handling

This makes the process fork creates new/fresh by default, and things
needed from procinfo are copied over one at a time.  The old way was
that the procinfo/procdata were identical.

In general, I tend to really dislike fork/exec: lots of hacks and pains
in the ass.  At least it isn't as bad as it used to be (when the proc
creation paths were totally separate).

7 years agoVcore list initialization. (XCC)
Barret Rhoden [Mon, 12 Sep 2011 22:57:50 +0000 (15:57 -0700)]
Vcore list initialization. (XCC)

There are three lists: active, bulk_preempted, and inactive/yielded.  We
don't use them in this commit; we just get them in place.  They have a
few purposes.  In the long run, it'll help the kernel with bulk
preemption.  For now, it will help with quickly finding a new vcore (no
more scanning from vcore0).  In the middle run, event FALLBACK will be
able to find a destination quickly.

7 years agoMCS locks properly disable thread migration
Barret Rhoden [Mon, 12 Sep 2011 21:52:17 +0000 (14:52 -0700)]
MCS locks properly disable thread migration

Any time you disable notifs, you need to disable uthread migration too.
The reason for this is that we can't atomically disable interrupts on a
vcore, so we need to make sure we're not moved around in the instant
after we read vcoreid and before we actually disable notifs.  x86's
'cli' doesn't have this issue.  =)

I put an assert in disable_notifs() to catch any future callers that
don't do this.

Also note that disabling/enabling notifs isn't the only reason to
disable migration; we want to disable migration for code that requires
staying on a vcore.  We don't necessarily want to turn it off an on at
exactly the same call sites as enable/disable notifs.  Check
uthread_yield() for an example (note it doesn't even enable_notifs()
directly).

7 years agoUses vcore_yield() for the preempt_pending path
Barret Rhoden [Mon, 12 Sep 2011 21:21:03 +0000 (14:21 -0700)]
Uses vcore_yield() for the preempt_pending path

I'm considering getting rid of the preemption pending business
completely, and just dealing with it afterwards.  But so long as we have
it, we need to make it work so that we don't lose INDIR messages by
yielding without checking events, etc.

7 years agoAdded gawk check to the Makefile
Kevin Klues [Thu, 8 Sep 2011 22:40:35 +0000 (15:40 -0700)]
Added gawk check to the Makefile

7 years agoSparc's cpu_halt() enables interrupts
Barret Rhoden [Wed, 31 Aug 2011 21:16:11 +0000 (14:16 -0700)]
Sparc's cpu_halt() enables interrupts

This isn't atomic, so may suffer from the race mentioned above.  This
compiles and runs, barely.  I say barely since there seem to be some
other sparc issues atm (running mhello, for instance).

7 years agoFixes race where we'd ignore a kmsg when halting
Barret Rhoden [Wed, 31 Aug 2011 02:24:04 +0000 (19:24 -0700)]
Fixes race where we'd ignore a kmsg when halting

If an interrupt came in at the wrong time, right after PRKM returns
(more specifically, right after it turns on interrupts but after it
thought the list was empty), then we'd halt and miss the message til the
next interrupt.

To fix this, we want cpu_halt() to mean "turn on interrupts and then
halt the core, atomically".  x86 does this via some irq_handler()
hacking, though from what I've seen, "sti;hlt" won't get interrupts
before the hlt (not sure if this is intentional or not).

Other archs (sparc/riscv) will need to support similar semantics in
their cpu_halt(), as the code is now.  Alternatively (and slightly
preferred), we can shut down the core completely and have it come back
up and come in through the top of smp_idle().

7 years agoEvent queue throttling (XCC)
Barret Rhoden [Mon, 29 Aug 2011 22:06:19 +0000 (15:06 -0700)]
Event queue throttling (XCC)

If an INDIR alert is pending for an ev_q, we won't send more til the
first one was acknowledged.  Some extras will make it through (due to
the nature of the race, but extras are always okay.

On a simple block test, this reduced the INDIRs by 10% - not a big deal.
If you want to turn it off for debugging reasons, comment out the
check/return block at the top of alert_vcore().  I want to leave it on
all the time, since it might help me catch a bug.

Reinstall your kernel headers / rebuild the parlib stuff.

7 years agoMakes looper.sh more useful
Barret Rhoden [Wed, 24 Aug 2011 23:55:51 +0000 (16:55 -0700)]
Makes looper.sh more useful

It now outputs the iteration, so you can detect a lockup more easily.

7 years agoAllows uthread_init() to be called repeatedly
Barret Rhoden [Mon, 22 Aug 2011 23:53:50 +0000 (16:53 -0700)]
Allows uthread_init() to be called repeatedly

So a 2LS can repurpose a thread, getting a fresh TLS, etc.  There's an
assertion that could trip (the flags and sysc check), though no one
should have a uthread with an old sysc.  'flags' could go either way,
but for now we want to catch "DONT_MIGRATE" being turned on.

7 years agouthread creation is now init, slims 2ls sched_ops
Barret Rhoden [Mon, 22 Aug 2011 23:28:30 +0000 (16:28 -0700)]
uthread creation is now init, slims 2ls sched_ops

2LSs now create their threads however they want, and then call
uthread_init() on them.  Later, they must call uthread_cleanup().

Thread creation/destruction is more 'top-down' this way, and the 2LS
must be sure to call uthread_lib_init() in its initialization routines,
and call uthread_cleanup() when it is done with a uthread.

With great power comes great responsibility.

7 years agoreadline() sends a \n when it got a \r
Barret Rhoden [Tue, 16 Aug 2011 00:12:26 +0000 (17:12 -0700)]
readline() sends a \n when it got a \r

We tend to treat \n as \r, like in a printk().  Similarly, we treat lone
\rs as \ns.  The serial port actually sends just \rs, not \r\n.
Basically, we treat \r and \n similarly.  When writing to the serial
port, they are the same.  When writing to the monitor, \n does a \r too,
but you can do a \r alone.

It's all rather ugly.  One way (a long-term better way) to deal with
this would be to make \n and \r do what they are supposed to do at the
device level, and change printk() to add \rs to its \ns.

Things would be a little nicer if minicom would send a \n.

7 years agoChecks for non-VCPD mboxs and INDIRs
Barret Rhoden [Mon, 15 Aug 2011 22:24:44 +0000 (15:24 -0700)]
Checks for non-VCPD mboxs and INDIRs

Seems the easiest place to check for INDIRs to VCPD mboxes.  It won't
catch all of them btw, but it's userspace's responsibility to not screw
this up too bad.

7 years agoev_qs can request fallback to active vcores (XCC)
Barret Rhoden [Mon, 15 Aug 2011 22:02:27 +0000 (15:02 -0700)]
ev_qs can request fallback to active vcores (XCC)

Fallback allows vcores to yield and not worry about missed INDIR events.
Read the documentation.

2LS writers can use vcore_yield() in a loop to try and yield properly.
Note that this will return.  Check the pthread code for an example of
how to handle this.

Reinstall your kernel headers.

7 years agoHelper to determine if a vcore is online / mapped
Barret Rhoden [Mon, 15 Aug 2011 21:58:53 +0000 (14:58 -0700)]
Helper to determine if a vcore is online / mapped

Mapped to a pcore, which means it is either online or will be soon (kmsg
in flight).  For the most part, 'mapped' means 'online'.  Might change
this later, to differentiate between existing, not existing, and
actually running (similar to how VM works: mapped != paged in).

7 years agoSeparates EVENT_INDIR from EVENT_IPI (XCC)
Barret Rhoden [Thu, 11 Aug 2011 22:21:15 +0000 (15:21 -0700)]
Separates EVENT_INDIR from EVENT_IPI (XCC)

Previously, and IPI implied and INDIR.  Now you can do them
independently, such as if you want INDIR messages that you'll poll out
of the VCPD.  Read the new Documentation.

Recompile / reinstall your kernel headers.

7 years agoFixes pthread thread0 initialization
Barret Rhoden [Wed, 10 Aug 2011 22:34:26 +0000 (15:34 -0700)]
Fixes pthread thread0 initialization

Need to have thread0 be a full pthread.  Previously, we'd have issues if
we had that thread exit while the program was still running (it'd try to
free its stack and get messed up, among other things).

7 years agouthread_exit() replaced with uthread_destroy()
Barret Rhoden [Thu, 4 Aug 2011 22:58:02 +0000 (15:58 -0700)]
uthread_exit() replaced with uthread_destroy()

For 2LSs that want to be able to destroy inactive threads from another
context, so that they can cache the.  This also simplifies uthread code
a bit.

7 years agoHelpers for converting time to and from tsc ticks
Barret Rhoden [Thu, 4 Aug 2011 06:53:14 +0000 (23:53 -0700)]
Helpers for converting time to and from tsc ticks

Don't refer to system_timing.tsc_freq directly.  The helpers handle
things such as wraparound/overflow, which was definitely a problem when
dealing with nsec.

Incidentally, wraparound/overflow is possibly why Dave had those
"impossible" numbers back in the day.

7 years agoCleaned up the 'timer interfaces'
Barret Rhoden [Mon, 1 Aug 2011 21:58:13 +0000 (14:58 -0700)]
Cleaned up the 'timer interfaces'

Things were a bit ghetto.  Now there is just time.h, one for ros/, one
for kern, and one for the arches.  x86 still uses apic.h for all its
crap, but no one else in kern/ needs to know about that.

7 years agoUCQ debug function
Barret Rhoden [Mon, 1 Aug 2011 21:11:26 +0000 (14:11 -0700)]
UCQ debug function

Call it via kfunc for now.  You'll need userspace to print out its ucq
address if you're going to call this from the monitor or something.
 Please enter the commit message for your changes. Lines starting

7 years agoFixes crappy address space management in arsc code
Barret Rhoden [Mon, 1 Aug 2011 21:05:45 +0000 (14:05 -0700)]
Fixes crappy address space management in arsc code

Old version was pretty clunky about when and how it switched contexts,
and might have been leaking proc refcnts if you had current loaded while
handling remote calls.

Note: I don't have code that actually uses this stuff, but it probably
works.  Dave can take a look with stuff from his branch if there is a
concern this doesn't work.

7 years agoHelpers for temporarily changing address spaces
Barret Rhoden [Mon, 1 Aug 2011 20:56:07 +0000 (13:56 -0700)]
Helpers for temporarily changing address spaces

Often the kernel wants to work in a process's context, but isn't
naturally in it, such as sending events from remote cores in interrupt
context, or from a management core.  Use the switch_to() and
switch_back() helpers for this.  Pair them up, etc.

7 years agoAlternate ev_mbox setting for pthreads
Barret Rhoden [Mon, 1 Aug 2011 18:47:06 +0000 (11:47 -0700)]
Alternate ev_mbox setting for pthreads

I have an example of how to use a single ev_mbox for all syscalls, while
having separate ev_qs per vcore.  Manually turn it on (and the default
version off) in pthread.c if you want.  I'm probably the only one that
will use it, since it is a nice way to hammer on UCQs (which is how I
found the recent bug).

7 years agoFixes race in UCQ consumer
Barret Rhoden [Mon, 1 Aug 2011 18:42:14 +0000 (11:42 -0700)]
Fixes race in UCQ consumer

During a page transition and under contention, we could get a slot that
is ahead of the producer.

7 years agoPthread syscall ev_qs no longer use VCPD mboxes
Barret Rhoden [Fri, 29 Jul 2011 23:47:02 +0000 (16:47 -0700)]
Pthread syscall ev_qs no longer use VCPD mboxes

2LSs (and anyone) should not use the VCPD ev_mboxes.  Message delivery
to the VCPD should be for messages meant to go to that specific vcore,
about that vcore's business.

One such bit of business is the indirection event EV_EVENT, telling it
the reason for an IPI is to check a particular event queue (such as the
syscall queue).

You want to decouple these so that different vcores can handle
unblocking threads that slept on a separate vcore, which is necessary if
you want a vcore to yield when it has no work to do but when there are
outstanding syscalls/uthreads.  If we used the VCPD, then another core
would have to process messages of another core's VCPD, which would
include messages that were not meant for the running core - such as
"preempt pending".

Also note that a 2LS could easily have one ev_q for all blocking
syscalls, or even multiple ev_qs (so you can specify IPI targets) but
with one global ev_mbox that all the ev_qs point to (and contend on).
This assumes there are no bugs (which there are).

7 years agoFixes event_q "get" interfaces to work with UCQs
Barret Rhoden [Fri, 29 Jul 2011 23:35:19 +0000 (16:35 -0700)]
Fixes event_q "get" interfaces to work with UCQs

One of the differences betwene UCQs and BCQs is that UCQs need to be
initialized.  I put some code in the kernel to catch uninitialized UCQs
in _M mode, which shouldn't happen, to help debug this.

For the event and ucq init code, the main difference between the raw and
normal functions is whether or not you manage your own memory.  Doing
one big mmap should be faster if you're making lots of big ev_qs (and
therefore lots of ucqs).

7 years agoRemoved event overflow handling
Barret Rhoden [Thu, 28 Jul 2011 23:48:13 +0000 (16:48 -0700)]
Removed event overflow handling

You can still request a bit for a message, but we no longer deal with
true overflow, nor any related system-recovery.  The Documentation still
talks about overflow a bit, in case we need to revisit these issues.

7 years agoReplaces BCQs with UCQs (XCC)
Barret Rhoden [Thu, 28 Jul 2011 22:28:19 +0000 (15:28 -0700)]
Replaces BCQs with UCQs (XCC)

This doesn't change anything extra.  For instance, the overflow
detection and handling code is still in place.

Reinstall your kernel headers, etc, though you shouldn't need a full
cross compiler rebuild.

7 years agoRemoved extraneous event/bcq utilities
Barret Rhoden [Thu, 28 Jul 2011 22:11:32 +0000 (15:11 -0700)]
Removed extraneous event/bcq utilities

mon_bcq() was getting useless quickly.  It helped with a brutal bug, but
isn't needed in its older form any more.

event_activity() wasn't particularly useful.  The only "legit" use was
to poll in syscall.c, which I want to discourage.  We might bring it
back in the future, but only if there is real need.

7 years agoEvent queues no longer use KVAs
Barret Rhoden [Thu, 28 Jul 2011 20:13:19 +0000 (13:13 -0700)]
Event queues no longer use KVAs

For VCPDs (in procdata), we had been accepting KVAs for ev_mboxes, even
if the user supplies them.  While it was correct, it was a bit error
prone, and since we're now in the business of carefully using
user-pointers, I cleaned this out.  Also UCQs (by fiat, for the same
reasons) need to be in user-RW-space, which would be a problem with the
ev_mbox.

7 years agoAdds 'hashlocks' and uses them for UCQs
Barret Rhoden [Tue, 26 Jul 2011 21:37:47 +0000 (14:37 -0700)]
Adds 'hashlocks' and uses them for UCQs

Hashlocks are just an array of spinlocks, and you pick your particular
lock based on some key's hash.  I'm curious to see if they are any
better than spinlocks, and at what point they are worth using.  For our
UCQ code - they probably aren't, but are rather cool.  We'd need some
serious event delivery to the same process in parallel to start
contending on the proc_lock.

7 years agoUCQs (XCC)
Barret Rhoden [Mon, 25 Jul 2011 23:27:44 +0000 (16:27 -0700)]
UCQs (XCC)

Unbounded concurrent queues, will eventually replace the BCQs in event
queues.  Don't manually call tests/ucq; it won't work.  If you want to
use them, you'll need to rebuild your cross compiler / reinstall your
kernel headers.  Future commits will actually use these.

Check the Documentation for specifics.

7 years agoClarifies 'handler-style' usage of alarms
Barret Rhoden [Mon, 25 Jul 2011 21:55:29 +0000 (14:55 -0700)]
Clarifies 'handler-style' usage of alarms

Since you shouldn't use an a_waiter on the stack if you aren't sleeping.

7 years agomm.h directly includes ros/mman.h
Barret Rhoden [Tue, 19 Jul 2011 22:43:56 +0000 (15:43 -0700)]
mm.h directly includes ros/mman.h

Minor thing, but most all users of mm.h would need ros/mman.h for the
flags to do_mmap().  Fixing it now before adding files that do this.

7 years agoarch/mmu.h contents now in ros/arch/mmu.h (XCC)
Barret Rhoden [Tue, 19 Jul 2011 18:47:15 +0000 (11:47 -0700)]
arch/mmu.h contents now in ros/arch/mmu.h (XCC)

This exposes certain constants to processes that they'll need to do
things like read page tables, handle segmentation (which we already do
for TLS), agree with the kernel on what the page offset is, etc.  This
will be useful later, and cleans up a couple todos.  Things were crappy
ever since we moved just a couple items at a time to ros/, but leaving
the rest in arch/.

For now, I'll leave the arch/mmu.hs, in case we come up with something
that should be kernel-only.

If this breaks things in RISC-V, please fix but leave the macros
exposed.  I'll be using PGOFF and PTE_ADDR later, among other things.

Rebuild your cross compiler / reinstall your kernel headers.

7 years ago__do_mmap() also adjusts anonymous addresses
Barret Rhoden [Tue, 19 Jul 2011 18:19:33 +0000 (11:19 -0700)]
__do_mmap() also adjusts anonymous addresses

Necessary for kernel do_mmap() calls that avoid mmap().

7 years agois_user_rwaddr() now takes a length parameter
Barret Rhoden [Wed, 13 Jul 2011 19:35:13 +0000 (12:35 -0700)]
is_user_rwaddr() now takes a length parameter

7 years agoremoved gunk from manager_waterman()
Andrew Waterman [Wed, 13 Jul 2011 03:00:17 +0000 (20:00 -0700)]
removed gunk from manager_waterman()

7 years agofixed atomic_read to be assumed volatile
Andrew Waterman [Wed, 13 Jul 2011 02:55:36 +0000 (19:55 -0700)]
fixed atomic_read to be assumed volatile

7 years agoRISC-V compile fixes
Andrew Waterman [Tue, 12 Jul 2011 19:46:42 +0000 (12:46 -0700)]
RISC-V compile fixes

7 years agosome RISC-V fixes
Andrew Waterman [Tue, 12 Jul 2011 19:34:03 +0000 (12:34 -0700)]
some RISC-V fixes

7 years agoFixed compile error on SPARC port
Andrew Waterman [Fri, 8 Jul 2011 06:07:50 +0000 (23:07 -0700)]
Fixed compile error on SPARC port

7 years agoe1000 uses the new kernel dynamic VA mapping
Barret Rhoden [Tue, 14 Jun 2011 23:40:16 +0000 (16:40 -0700)]
e1000 uses the new kernel dynamic VA mapping

Also, we no longer need mmio_alloc(), which was doing both the VA
reservation as well as mapping, and only working about the APICS (which
was the old mmio_base).

7 years agoFixes showmapping to work with non-page back maps
Barret Rhoden [Tue, 14 Jun 2011 23:33:21 +0000 (16:33 -0700)]
Fixes showmapping to work with non-page back maps

Should never have been using page_lookup in the first place.  Ugh.
Also, we finally show the permission bit.  It's a bit more important now
that callers of map_vmap_segment() have to set PTE_P.

7 years agoBasic functions to dynamically adjust kernel vmaps
Barret Rhoden [Tue, 14 Jun 2011 01:14:17 +0000 (18:14 -0700)]
Basic functions to dynamically adjust kernel vmaps

For now, you can't dealloc or unmap regions.  There are two parts:
reservation/alloc/getting of a chunk of vm space (growing down from
KERN_DYN_TOP), and then mapping those vaddrs to paddrs.  This is not
like page_insert - there might not be real pages involved.  You'll have
to handle your own refcnting or otherwise handle whatever you are
mapping.

7 years agoKernel static mappings grow down, APICs remapped
Barret Rhoden [Sat, 11 Jun 2011 00:51:03 +0000 (17:51 -0700)]
Kernel static mappings grow down, APICs remapped

The KERNBASE physical memory mapping still grows up from KERNBASE to the
top of virtual memory.  This top is now KERN_VMAP_TOP, instead of the
old IOAPIC_BASE.  If you arch needs the kernel to never map above a
certain VA, then set this.  RISCV needs it due to its crazy static
kernel aliasing.

RISCV side note: I moved the "max vaddr" stuff (formerly IOAPIC) to the
size dependent code in mmu.h, since I think the old version was wrong
for 32 bit versions.  Feel free to move it back.

All non-KERNBASE mappings will now grow down from KERNBASE, such as VPT,
and the APICs (L and IO).  Any static ones your arch needs should be
defined, and set the value KERN_DYN_TOP at the bottom of the last one.
From this point, all dynamic mappings will occur (in future patches,
when we have dynamic mappings), down to ULIM.

While the LAPIC and IOAPIC don't need to be a part of the kernel
interface (in ros/mmu.h or memlayout.h), the VPT symbol does for now, so until
we figure out how to use the UVPT, I'm leaving it there.

Also, the LAPIC and IOAPIC are now mapped in their new locations, which
are still called LAPIC_BASE nand IOAPIC_BASE.  Previously that name was
overloaded for both VA and PA, and now the PAs have are *_PBASE.

7 years agoExt2: helper function pointers take longs
Barret Rhoden [Wed, 8 Jun 2011 22:20:40 +0000 (15:20 -0700)]
Ext2: helper function pointers take longs

Instead of void*s.  Same deal as with the kernel messages.  Also note
that ext2 uses 32bit ints a lot (like with load_inode()), since it is
part of the disk format.

7 years agoKernel message parameters are now longs
Barret Rhoden [Wed, 8 Jun 2011 21:17:51 +0000 (14:17 -0700)]
Kernel message parameters are now longs

Instead of void*s.  This helps code be 64-bit friendly, and we avoid
casting to and from pointers when we don't care about pointers.

7 years agoUTOP -> UWLIM
Barret Rhoden [Wed, 8 Jun 2011 20:49:41 +0000 (13:49 -0700)]
UTOP -> UWLIM

Clarifies (and fixes) the confusing usage of UTOP as the upper limit to
user-writable VAs.  ULIM is the max accessible, and UWLIM is the max
writeable.

This touches the kernel headers, but the values haven't changed so you
shouldn't need to rebuild glibc or anything.

7 years agoDefault/static stacks are now PGSIZE
Barret Rhoden [Wed, 8 Jun 2011 20:18:06 +0000 (13:18 -0700)]
Default/static stacks are now PGSIZE

We might up it to two pages in the future, but whatever we do needs to
be kept in sync with kthread stacks, which are one page.

7 years agoRemoved KSTACKTOP
Barret Rhoden [Wed, 8 Jun 2011 19:29:21 +0000 (12:29 -0700)]
Removed KSTACKTOP

This was the virtual mapping of core0's kernel stack (aka, bootstack)
into space below KERNBASE.  We actually haven't even used the virtual
mapping for about 8 months - since kthreadding back in d6177dffd9735.

7 years agoAtomics rewrite (XCC)
Barret Rhoden [Wed, 8 Jun 2011 01:29:10 +0000 (18:29 -0700)]
Atomics rewrite (XCC)

The atomics have been slowly drifting out of control, esp with 64-bit
unfriendliness; this patch ought to fix some things.

1) All atomic ops take an atomic_t*, and if there are values added or
subtracted, they are longs.  The atomic_t helps ensure we only use
atomic ops on atomic variables.

2) Atomic ops on other types have their own functions, denoting the
type, such as atomic_cas_u32().  Careful using these, since you may have
other references to those vars that aren't atomic.

3) BCQs use u32s for their buffer indexes.  If we have programs that are
32 bit on a 64 bit kernel, we would have trouble if we tried using 64
bit values.

4) k/i/atomic.h now is the source of the function prototypes.  They are
extern inlines, which requires -fgnu-89inline (which we've been using),
allowing arches to implement the functions however they'd like, such as
with static inlines or with a regular function (like x86's
spinlock_debug() or riscv's CAS ops).

5) Some users of atomic_swap were cleaned up to represent its status as
an atomic, mostly in userlevel locking code.  Userlevel condition
variables use swap_u32(), which may not be what people want.  That bit
of code is a bit unmaintained at this point.

6) Userspace does not unify its atomics in an inc/atomic.h, since glibc
has its own atomic.h.  There will be a reckoning for userspace at some
point, dealing with the collision of atomic naming with glibc.  It's not
really the kernel's concern.  Also note that I didn't want to force the
-fgnu89-inline on userspace.

7) Rebuild your cross compiler/glibc.  Everything compiles on sparc and
x86.  I haven't been able to try riscv yet.

7 years agoFixes sparc compilation error
Barret Rhoden [Mon, 6 Jun 2011 23:17:32 +0000 (16:17 -0700)]
Fixes sparc compilation error

Sparc doesn't like our new fields in the kernel messages.  We'll 8-byte
align them from now on.  If you change the size of a kernel message, be
sure to update k/a/s/trap.h.

7 years agoKthread stack poisoning
Barret Rhoden [Mon, 6 Jun 2011 21:10:11 +0000 (14:10 -0700)]
Kthread stack poisoning

This has a bunch of asserts to check when sleeping or restarting a
kthread to make sure that we aren't using an active kernel stack.

The option will eventually go away or change when we have kthread
structs at the top of stacks.

For now, this will probably fail on sparc and riscv, so don't turn it on
for them.  Its not a big deal, since this is meant to debug heavy
kthreading.

7 years agoSafer assertions related to __up_sem()
Barret Rhoden [Mon, 6 Jun 2011 20:19:41 +0000 (13:19 -0700)]
Safer assertions related to __up_sem()

When calling __up_sem(), you can ask it to assert that the list is empty
after signalling one.  This is for code that wants a semaphore of only
one item and wants to put in some 'helpful' asserts.  By having __up_sem
do it, we avoid the temptation to check after waking a kthread, but more
importantly we do the check inside the lock.  Doing otherwise might trip
the assert for the wrong reason.

7 years agoCleaned up finishing syscalls
Barret Rhoden [Mon, 6 Jun 2011 19:59:50 +0000 (12:59 -0700)]
Cleaned up finishing syscalls

The name of the old signal_current_sc() was a bit misleading, and wasn't
using the same finishing code as normal syscalls.  While the latter
isn't a big deal, this might avoid issues in the future.  Regardless,
userspace needs to be careful of and not trust events (or polling) for
weird syscalls that don't return normally.

7 years agoFixes race with SC_DONE and event overflow (XCC)
Barret Rhoden [Mon, 6 Jun 2011 19:11:39 +0000 (12:11 -0700)]
Fixes race with SC_DONE and event overflow (XCC)

In VMs, or possibly with poor interrupt timing, the kernel would be
delayed such that the 2LS would deregister and handle all events before
the kernel would send an ev_msg, causing a uthread to be restarted
twice.

Rebuild your cross-compiler/glibc.

7 years agoatomic_and()
Barret Rhoden [Mon, 6 Jun 2011 19:10:09 +0000 (12:10 -0700)]
atomic_and()

Should work for RISCV - I don't have the compiler to check yet.

7 years agoDon't touch the waiter after waking
Barret Rhoden [Fri, 3 Jun 2011 18:57:54 +0000 (11:57 -0700)]
Don't touch the waiter after waking

If the kthread runs on another core, it'll unwind its stack and
dealloc/clobber the waiter you just woke up.  Like many other places in
the code, once you wake / unlock / unblock something, don't touch it
again.

7 years agoDon't cache pcpui across potential kthread blocks
Barret Rhoden [Fri, 3 Jun 2011 18:55:41 +0000 (11:55 -0700)]
Don't cache pcpui across potential kthread blocks

When you come back up the stack, you could be on a different core if
your kthread migrated, and your pcpui would be wrong.

7 years agoa risc-v single-core process works!!
Andrew Waterman [Sat, 4 Jun 2011 00:38:34 +0000 (17:38 -0700)]
a risc-v single-core process works!!

7 years agouser_mem_check/assert now also check for alignment
Andrew Waterman [Thu, 2 Jun 2011 20:50:36 +0000 (13:50 -0700)]
user_mem_check/assert now also check for alignment

7 years agodecoupled ULIM from KERNBASE. rebuild your xcc.
Andrew Waterman [Wed, 1 Jun 2011 11:24:31 +0000 (04:24 -0700)]
decoupled ULIM from KERNBASE.  rebuild your xcc.

now, each ros/arch/mmu.h defines ULIM individually.

apologies for not being able to test this for x86.  it does compile, at least.

7 years agoadded NOVPT option to disable VPT/UVPT mappings
Andrew Waterman [Wed, 1 Jun 2011 11:21:47 +0000 (04:21 -0700)]
added NOVPT option to disable VPT/UVPT mappings

7 years agofixes towards risc-v user programs running
Andrew Waterman [Wed, 1 Jun 2011 11:20:50 +0000 (04:20 -0700)]
fixes towards risc-v user programs running

7 years agoelf loader now mostly supports 64b elfs
Andrew Waterman [Wed, 1 Jun 2011 11:18:08 +0000 (04:18 -0700)]
elf loader now mostly supports 64b elfs

7 years agoBroken static_assert failed to catch my bug :(
Andrew Waterman [Wed, 1 Jun 2011 08:20:18 +0000 (01:20 -0700)]
Broken static_assert failed to catch my bug :(

7 years agoSynced up RISC-V build
Andrew Waterman [Wed, 1 Jun 2011 02:21:33 +0000 (19:21 -0700)]
Synced up RISC-V build

7 years agonew 64b kernel memory map (not userspace yet)
Andrew Waterman [Wed, 1 Jun 2011 02:12:02 +0000 (19:12 -0700)]
new 64b kernel memory map (not userspace yet)

in short, KERNBASE = 0xFFF8 0000 0000 0000 (the most negative 48b addr),
and KERNSIZE = L1PGSIZE (512 GB).  kernel static symbols are referenced
through the KERN_LOAD_ADDR mapping, which is the upper 2GB, i.e.
KERN_LOAD_ADDR = 0xFFFF FFFF 8000 0000.  since all addresses in this range
are canonicalized signed 32-bit numbers, kernel symbols can be referenced
with 32b sign-extended addresses, reducing code size.

7 years agoKernel message sanity checks
Barret Rhoden [Tue, 31 May 2011 18:08:14 +0000 (11:08 -0700)]
Kernel message sanity checks

Ensures the message went to the proper endpoint.  Now that the slab
allocator was fixed, this shouldn't happen again, but I can imagine
other bugs that would cause it, with crazy results.

Also added a couple other asserts / TODOs.

7 years agoKthread stack freeing is more "accurate"
Barret Rhoden [Tue, 31 May 2011 18:02:30 +0000 (11:02 -0700)]
Kthread stack freeing is more "accurate"

The old version assumed stacktop was page aligned, and PGSIZE above its
actual page.  While this ought to be true on x86, it won't always be
(like if we put the struct kthread at the top of the page) or if we
offset the stacktops per-core (a debugging technique).

7 years agoFixes ancient slab bug
Barret Rhoden [Tue, 31 May 2011 17:38:44 +0000 (10:38 -0700)]
Fixes ancient slab bug

We shouldn't have been locking at all in kmem_cache_grow().  I made it
internal, since no outsiders should be calling it either.  Had we
properly locked, we would have deadlocked and noticed this when it was
written, 2.5 years ago.

Fun fact: I found this in a storm of bugs involving massive kthreading.
It looked like kmsgs (from a slab) were getting misrouted, and multiple
cores were clobbering each others kmsgs (including the kthread*
payload)...

7 years agoBacktrace reports the last entry
Barret Rhoden [Mon, 30 May 2011 20:32:25 +0000 (13:32 -0700)]
Backtrace reports the last entry

This helps for some odd debugging situations, esp since sometimes the
ebp chain is optimized out and we miss spots (like with proc_restartcore
and sysenter_callwrapper()).