akaros.git
7 years agoSCPs can sleep on events (XCC)
Barret Rhoden [Fri, 16 Mar 2012 19:39:23 +0000 (12:39 -0700)]
SCPs can sleep on events (XCC)

If single-core processes yield that aren't 'being nice', they will block
waiting for an event.  Otherwise, the process is simply giving up the
processor for someone else, even though it has work to do.

The meaning of being_nice differs between SCPs and MCPs.  MCPs will
never give up if they have work to do, unless they think a preemption is
coming in.  Might consider getting rid of the whole SCP 'sched_yield'
approach (arguably, it's the kernel's job) for _Ss, but whatever.

Rebuild your cross compiler, making sure to replace sched_yield.c in
your glibc directory.  Otherwise, sched_yielders (like busybox) will
accidentally block.

7 years agoSCPs can register ev_qs for syscalls (XCC)
Barret Rhoden [Fri, 16 Mar 2012 00:09:22 +0000 (17:09 -0700)]
SCPs can register ev_qs for syscalls (XCC)

Right now, they just yield and get restarted right away, while waiting
for the event (and actually they just check the sysc flag).  Future
patches will have them become WAITING.

Rebuild your cross compiler/userspace.

7 years agoRemoved unnecessary/fauly assert
Barret Rhoden [Thu, 15 Mar 2012 20:15:46 +0000 (13:15 -0700)]
Removed unnecessary/fauly assert

This safely trips if SCPs kthread and yield in a loop while waiting.
Here's what happens:
1) process causes a kthread (sys_block)
2) process yields, leaving the core (no longer current or owning)
3) timer interrupt goes off and unblocks the kthread, which sets current
(but not owning)
4) kthread does not clear current - that's done in the
restartcore/smp_idle path.
5) ksched's timer tick goes off, causing its work to be done in a
routine kmsg
6) proc_restartcore executes the kmsg before abanonding
&) ksched kmsg calls proc_run_s

We actually don't want to abandon early - it's better to stay in that
context til after we check messages (avoid an extra TLB flush).  The old
assert was probably important a long time ago (back when owning_proc and
current were the same thing), or at least a "this is weird, check it
out."

Note the process is current, but not the owning proc.

7 years agoFixes bug in event headers (XCC)
Barret Rhoden [Thu, 15 Mar 2012 18:57:57 +0000 (11:57 -0700)]
Fixes bug in event headers (XCC)

Has been around since 16a868, haven't seen it hit yet, though it might
have been masking other bugs.

7 years agoEvent delivery to _S procs
Barret Rhoden [Thu, 15 Mar 2012 02:59:15 +0000 (19:59 -0700)]
Event delivery to _S procs

If an _S registers an ev_q, the kernel event delivery system will send
events to the process.  Events will go to vcore0's public mbox,
regardless of ev_flags, so long as the proc is an _S.  Processes can set
up ev_qs for whatever they want later, and then when they are MCPs, the
flags will kick in (and you don't have to change things).  That is how
processes should set up ev_qs for POSIX signals.

The code can also handle the process being descheduled, and the _S will
pop into vcore context when it starts up (if it wasn't already in vcore
context when it was stopped).

Receiving an event also should wake an _S, rescheduling it, though that
hasn't been tested yet (_Ss don't WAIT yet).

7 years agoAll apps now must link against parlib (XCC)
Barret Rhoden [Tue, 13 Mar 2012 21:21:29 +0000 (14:21 -0700)]
All apps now must link against parlib (XCC)

Glibc calls out to a low-level parlib function (vcore_event_init(), used
to enable event delivery of *all* processes) that needs to be linked in
to every binary, regardless of whether or not the process will be an
MCP.

In addition to linking against parlib, applications need to be built
with " -u force_parlib_symbols ", which forces the linker to find the
strong version of symbols weakly used in glibc's start.c.

All test code has these flags/libraries set, but external apps need it
too.  Busybox, in particular, needs the patch in tools/patches to force
linking with parlib.

Rebuild your cross compiler, and install-libs (esp before rebuilding
busybox).  At a minimum, you need to copy start.c to the glibc-2.14.1/
tree and rebuild.  If that doesn't make sense, then just do a full
rebuild of glibc.

7 years agouthread_vcore_entry() can handle not having a 2LS
Barret Rhoden [Tue, 13 Mar 2012 00:38:34 +0000 (17:38 -0700)]
uthread_vcore_entry() can handle not having a 2LS

_Ss that never link in a 2LS will pop up in vcore_entry() when receiving
events.  This patch allows them to restart current_uthread - sort of a
'default 2LS op'.  I thought of making it an actual member of
default_2ls_ops, but I didn't want 2LS writers to think it is actually a
real default choice for them.  It's just to make _S code work.

7 years agouthread_slim_init()
Barret Rhoden [Tue, 13 Mar 2012 00:33:34 +0000 (17:33 -0700)]
uthread_slim_init()

Allows the uthread code to manage thread0 in the absence of a 2LS.
Eventually, all processes will call uthread_slim_init(), which will be
useful for event delivery to _Ss.  Then processes that will become MCPs
will call uthread_lib_init and set up the full system (using 2LS
threads, instead of just struct uthreads).

7 years agoproc_yield() will abort if they want the core
Barret Rhoden [Mon, 12 Mar 2012 20:09:29 +0000 (13:09 -0700)]
proc_yield() will abort if they want the core

This saves the kernel scheduler the effort of reallocating the core.
This could trigger if there was a concurrent vcore_requester, though it
should be pretty rare.

7 years agoEvents that wake processes poke the ksched
Barret Rhoden [Sun, 11 Mar 2012 17:47:57 +0000 (10:47 -0700)]
Events that wake processes poke the ksched

Previously, the processes would wake up, but wouldn't tell the ksched.
The ksched would have to notice on its next tick, which could be 10ms
away (current ksched), or never (tickless kscheds).  For block_test,
which sleeps 5ms per loop, without this patch, you'd wait close to 5ms
til the next timer tick.  This patch cuts down block test to about
5.5sec (poke to run when avail), instead of 10sec (run on timer tick).

Unblocking is a big enough deal that it got its own callback, but we're
not using it for anything other than a RES_CORES poke right now.

7 years agoput_idle_core() called without the proc_lock
Barret Rhoden [Fri, 9 Mar 2012 22:18:54 +0000 (14:18 -0800)]
put_idle_core() called without the proc_lock

Minor changes to yield and preempt, we give back the core after
unlocking (like with previous patches).

Now, ksched's should be free to do whatever they want in put_idle.

7 years ago__proc_give_cores() no longer makes a callback
Barret Rhoden [Fri, 9 Mar 2012 21:26:42 +0000 (13:26 -0800)]
__proc_give_cores() no longer makes a callback

The put_idle_cores() callback could deadlock if kscheds ever did smart
things in that function.

Kernel schedulers can do more advanced things than in core_request().
For instance, one could attempt to give some cores to one proc, and if
that fails, just give the same pc_arr to the next in line (assuming it
needs them).  Right now, we don't support partial allocations, mostly
because it's the ksched'd job to know what you want and give no more
than that amount.

7 years agoRemoves the dumb version of take_allcores
Barret Rhoden [Fri, 9 Mar 2012 19:20:58 +0000 (11:20 -0800)]
Removes the dumb version of take_allcores

Part of a move to not call ksched trigger functions while holding the
proc_lock.  Until we do that, the ksched can (and will) deadlock if it
tries to do anything smart in the callbacks (like give cores to a
process).

7 years agoKsched interface cleanup, smp_idle() cleanup
Barret Rhoden [Thu, 8 Mar 2012 23:28:35 +0000 (15:28 -0800)]
Ksched interface cleanup, smp_idle() cleanup

Moves the logic about what a core should do when having nothing to do to
the ksched.

7 years agoFixes bug with abort_halt()
Barret Rhoden [Tue, 6 Mar 2012 01:47:46 +0000 (17:47 -0800)]
Fixes bug with abort_halt()

Could PF when dereferencing EIP when the page hadn't been populated yet
(like right after a sys_fork()).

7 years agoKsched is interrupt driven
Barret Rhoden [Mon, 5 Mar 2012 23:47:08 +0000 (15:47 -0800)]
Ksched is interrupt driven

schedule() is called from timer ticks, every 10msec.  It's just an
example of what any ksched can do.

7 years agoAlarm interface for incremental alarms
Barret Rhoden [Mon, 5 Mar 2012 23:45:11 +0000 (15:45 -0800)]
Alarm interface for incremental alarms

So you can reset an alarm for a new time, relative to the last alarm
(compared to 'relative to now').  This is useful if you want a periodic
tick, where you care about how much time passes.

Though you can always run into issues where you try to tick too fast for
the system to keep up, and you'll start to fall behind (setting alarms
for the past, etc), so anything serious is likely to need a more serious
solution.

7 years agoFCFS ksched gives out what it can
Barret Rhoden [Mon, 5 Mar 2012 22:24:03 +0000 (14:24 -0800)]
FCFS ksched gives out what it can

Previously, it would only give you cores if it could fully meet the
request (amt_min style) - now it just gives out what it can.

Less dumb, but still really dumb.

7 years agoMinimizes proc_locking in core_request
Barret Rhoden [Fri, 2 Mar 2012 22:54:21 +0000 (14:54 -0800)]
Minimizes proc_locking in core_request

__core_request() now needs the ksched lock held, instead of using the
proclock.  This does mean that you can have two concurrent core_requests
for different processes, but since the bulk of core_request is really
just dealing with the ksched's structures, this style makes more sense.

Also gets rid of the old return value of core_req, since we don't use
it.

7 years agoschedule() only hands out to _S if it's an LL core
Barret Rhoden [Fri, 2 Mar 2012 21:04:12 +0000 (13:04 -0800)]
schedule() only hands out to _S if it's an LL core

Not that schedule() is called on CG cores, but it might in the future.
Also, CG vs LL is going to be a ksched controlled thing (for the most
part).

7 years agoRemoves resource.c/h
Barret Rhoden [Fri, 2 Mar 2012 01:16:47 +0000 (17:16 -0800)]
Removes resource.c/h

Moves the only real functionality into the ksched (which will help with
the ghetto proc_wants_cores() calls).  core_request() is really just
"proc wants cores, find cores, give cores", which is the scheduler's
job.

7 years agoRemoves sys_resource_req (XCC)
Barret Rhoden [Thu, 1 Mar 2012 00:30:44 +0000 (16:30 -0800)]
Removes sys_resource_req (XCC)

Reinstall your kernel header (or the kernel will catch the invalid
syscall).

7 years agoUserspace reboot helper
Barret Rhoden [Thu, 1 Mar 2012 00:19:19 +0000 (16:19 -0800)]
Userspace reboot helper

With correct accents.

7 years agoBreaks up sys_resource_req (XCC)
Barret Rhoden [Thu, 1 Mar 2012 00:17:07 +0000 (16:17 -0800)]
Breaks up sys_resource_req (XCC)

sys_resource_req() did both a transition to _M as well as poking the
ksched.  This splits that into two separate syscalls.  At this point,
the way to do resource requests is to write into procdata and optionally
poke the ksched.

Reinstall your kernel header.

7 years agoResource requests use the procdata interface
Barret Rhoden [Wed, 29 Feb 2012 08:19:28 +0000 (00:19 -0800)]
Resource requests use the procdata interface

Also clarifies the semantics of vcore_request() (still using the "n more
than i currrently have", though that may change in a future patch).

Also removes the extra check/loop in vcore_request() (handle_it), to
make the pattern a little more clear.  The handle_it path was in case we
had more requests while we were in sys_res_req, and merely avoided
unlocking/relocking, which isn't a big deal.

Still using the syscall for the mcp transition or poking of the ksched.

7 years agoMoves resource requests to procdata (XCC)
Barret Rhoden [Wed, 29 Feb 2012 00:39:09 +0000 (16:39 -0800)]
Moves resource requests to procdata (XCC)

Userspace doesn't use it yet, but resource requests are via procdata
instead of a syscall.  Resource grants are in procinfo.

Reinstall your kernel headers / rebuild parlib apps.

7 years agoproc_yield() no longer messes with amt_wanted
Barret Rhoden [Tue, 28 Feb 2012 23:24:07 +0000 (15:24 -0800)]
proc_yield() no longer messes with amt_wanted

The only time the kernel will mess with it (for now) is in
__proc_wakeup(), so that the ksched will give them something.

7 years agoKsched tracks MCPs for their entire lifetime
Barret Rhoden [Tue, 28 Feb 2012 21:23:41 +0000 (13:23 -0800)]
Ksched tracks MCPs for their entire lifetime

_Ss still work like traditional schedulers - we tell the ksched about
them when they are runnable.  _Ms are always tracked, regardless of
running or not.

There's some minor races with proc state that give_cores can handle,
though I'd like to change that part a bit.

Also note that schedule() grabs proclocks.  Don't call this when holding
a proclock or from interrupt context.

7 years ago__proc_give_cores() can be called multiple times
Barret Rhoden [Sat, 25 Feb 2012 01:14:26 +0000 (17:14 -0800)]
__proc_give_cores() can be called multiple times

Once you're done giving cores, call __proc_run_m() to actually start it
up.  This patch moves the sending of the bulk preempt list events to
right before we run, so that you can give out small groups of cores
without having to run after each handout.  Check out core_request() for
an example.

This also moves the running of _Ms out of the ksched, though
core_request() is pretty close to the ksched anyway.  Regardless,
schedulers no longer need to track the difference between a RUNNABLE_M
and a RUNNING_M.

7 years agoBreaks proc_run() into _S and _M functions
Barret Rhoden [Fri, 24 Feb 2012 22:47:05 +0000 (14:47 -0800)]
Breaks proc_run() into _S and _M functions

Eventually, proc_run_m will be called internally (or will go away
completely).

7 years agoMoves proc runnable list to the ksched
Barret Rhoden [Thu, 23 Feb 2012 05:02:02 +0000 (21:02 -0800)]
Moves proc runnable list to the ksched

And changes the (totally unused) old procinfo option.  One minorly
ghetto thing is that whatever embedded structure the ksched wants to use
will need to be in the proc struct (TAILQ now, but later...).

7 years agoproc_run() now returns
Barret Rhoden [Wed, 22 Feb 2012 03:07:18 +0000 (19:07 -0800)]
proc_run() now returns

Previously, it would not return if you were running an _S.  Now, no code
has to worry about it not returning.

This was an artifact of the old implementation that required proc code
to immediately deal with popping user contexts.  Now that we have
current_tf and owning_proc in pcpui, proc_run() acts like
__proc_give_cores() and friends: it just tells the core (via pcpui) to
run you when the core has nothing else to do (smp_idle).

7 years ago_S -> _M and schedule()/core_request() work
Barret Rhoden [Wed, 22 Feb 2012 02:24:45 +0000 (18:24 -0800)]
_S -> _M and schedule()/core_request() work

A lot is in transition.  This step makes the transition code to _M mode
the province of process.c, instead of resource.c.  I kept around the old
_M->_S code, but don't seriously use it or plan on it ever being used.

7 years agoAllows no EXT2 block device
Barret Rhoden [Mon, 27 Feb 2012 21:26:40 +0000 (13:26 -0800)]
Allows no EXT2 block device

Note you still need to have the block device if you compile with EXT2
support.  This just lets people not use EXT2 and still build.

7 years agoFixes some RISCV compilation issues
Barret Rhoden [Mon, 27 Feb 2012 21:25:20 +0000 (13:25 -0800)]
Fixes some RISCV compilation issues

7 years agoFixes backtrace (x86, at least)
Barret Rhoden [Sat, 4 Feb 2012 00:07:38 +0000 (16:07 -0800)]
Fixes backtrace (x86, at least)

Probably due to the recent cross compiler change, we were enabling
omit-frame-pointer, which was breaking our backtrace implementation.

7 years agoPreserves mmaps of MAP_SHARED files across fork()
Barret Rhoden [Fri, 3 Feb 2012 23:44:09 +0000 (15:44 -0800)]
Preserves mmaps of MAP_SHARED files across fork()

mm.c's copy_pages() uses env_user_mem_walk(), which is probably faster
than a pgdir walk for each PTE, esp on 64 bit architectures.  Still, I
kept around code that can do the copy_page manually, since I'm not a
huge fan of the mem walk - I'll probably change its interface when the
need arises.

7 years agoFixes bug with mmapping beyond a file's last page
Barret Rhoden [Fri, 3 Feb 2012 21:02:07 +0000 (13:02 -0800)]
Fixes bug with mmapping beyond a file's last page

The kernel was page faulting.  Now, we check for it at do_mmap() time,
and recheck during handle_page_fault().  Linux sends a SIGBUS at access
time if you tried to access beyond the filesize.

Note that we still don't have any concurrency protection regarding the
file size.  Someone could be truncating the file right as you are
loading the page, but after you checked i_size.

7 years agoLoad elf program segments with the correct perms
Barret Rhoden [Fri, 3 Feb 2012 01:44:55 +0000 (17:44 -0800)]
Load elf program segments with the correct perms

We had been giving them all write access.  All the writable ones need to
be PRIVATE (so we don't mess with the original file).

Note that ld wants its EXEC sections to be loaded writable, despite the
elf header saying otherwise.  There's a decent chance we're doing
something wrong, somewhere.  Anyway, I talk about it in the code a bit,
so if you see weird things with permissions of binaries involving ld,
take a look.

7 years agoBetter file permission checks in mmap()
Barret Rhoden [Tue, 31 Jan 2012 23:14:42 +0000 (15:14 -0800)]
Better file permission checks in mmap()

The checks we do in mprotect are now done in mmap, with backup checks
done in handle_page_fault().  The checks (and the VFS!) could use a bit
of work.  Note that the VFS's check_perms() always allows access
(currently).

7 years agoFixes MAP_PRIVATE bug in mmap()
Barret Rhoden [Tue, 31 Jan 2012 04:00:30 +0000 (20:00 -0800)]
Fixes MAP_PRIVATE bug in mmap()

Flags were being set, instead of checking.  Further, we needed to make
private copies (or CoW) on any private mapping, independently of its
PROT status, due to some other issues we have with libc and loadelf.

Note that we have a couple other bugs still, related to mmap of files
across fork or mmap of regions of files exceeding the filesize.

7 years agoMoves the idlecoremap to the ksched
Barret Rhoden [Wed, 25 Jan 2012 19:10:39 +0000 (11:10 -0800)]
Moves the idlecoremap to the ksched

There's a lot of stuff built in to process code that belongs more in the
scheduler - such as the idlecoremap.  That one was an old example of how
things could be done.

The interfaces in sched.h are pretty ghetto, and a lot of this stuff is
just intermediate code.  And that hideous code for initing the number of
idle cores was simply moved to sched.c.

7 years agoBulk preemption uses the bulk preempt list
Barret Rhoden [Mon, 23 Jan 2012 23:40:23 +0000 (15:40 -0800)]
Bulk preemption uses the bulk preempt list

Using the old, ghetto __proc_preempt functions.  Also when you take the
last core using these, the process will be put in RUNNABLE_M and
rescheduled.

7 years agoFixes occasional STAB error on x86
Barret Rhoden [Mon, 23 Jan 2012 23:33:02 +0000 (15:33 -0800)]
Fixes occasional STAB error on x86

We were erroring out unnecessarily, which was breaking things like
kfunc.

7 years ago__proc_give_cores() can now handle bulk preemption
Barret Rhoden [Thu, 19 Jan 2012 02:45:11 +0000 (18:45 -0800)]
__proc_give_cores() can now handle bulk preemption

Or so I think.  We don't actually use the BP list yet.

7 years agoReorganizes the __proc_take cores functions
Barret Rhoden [Wed, 18 Jan 2012 22:06:22 +0000 (14:06 -0800)]
Reorganizes the __proc_take cores functions

Making them more suitable to bulk preemption.

7 years agoFixes rare race with notifying unmapped vcores
Barret Rhoden [Wed, 18 Jan 2012 21:39:27 +0000 (13:39 -0800)]
Fixes rare race with notifying unmapped vcores

Fun fact: this race only presented itself when we had the next commit
applied for block_test, even though we don't call any of the functions
that the next commit changes.

7 years agoRemoves __proc_set_allcores()
Barret Rhoden [Wed, 11 Jan 2012 22:28:50 +0000 (14:28 -0800)]
Removes __proc_set_allcores()

Never was used, and I'm cleaning up the proc core management.

7 years agoFixes bug with run_current_uthread()
Barret Rhoden [Tue, 20 Dec 2011 10:02:30 +0000 (02:02 -0800)]
Fixes bug with run_current_uthread()

The code had been assuming that if you had a current_uthread, that it
was RUNNING and its TF was loaded in the vcpd notif_tf.  That's not
always the case.

Previously, it wasn't the case for brief moments between setting current
and popping that TF.  During one of those moments, you could handle a
message that made you start over at vcore entry (if there was a
CHECK_MSGS for instance, or a handle_vcpd_mbox()).  When you restarted
in vcore context, you could get to a run_current_uthread() that assumed
it was running out of the notif_tf.

Anyway, now run_current_uthread() and run_uthread() are two wrappers
around the real __run_current_uthread(), which does the heavy lifting,
especially managing the uthread TF and related flags.  The wrappers are
mostly for setting cur_uth and debugging( which is the main reason I
have those uthread states and whatnot).

7 years agoFixes rare deadlock in user-side ucq
Barret Rhoden [Tue, 20 Dec 2011 01:47:18 +0000 (17:47 -0800)]
Fixes rare deadlock in user-side ucq

In that loop, we spin on userspace.  If that vcore was preempted in its
short window (message reception), and we were the last vcore, and we got
to the spinning loop before getting the preempt message, then we'd
deadlock.  Side note: this hasn't happened yet.

7 years agoVcore preemption spinning helpers
Barret Rhoden [Tue, 20 Dec 2011 01:40:11 +0000 (17:40 -0800)]
Vcore preemption spinning helpers

Provides two helpers for vcore code, which should be used when you spin
and wait on another vcore that could be preempted.  If you want to spin
a little before trying to see if you are spinning due to a preemption,
use the cpu_relax_vc() call.  o/w, directly call ensure_vcore_runs().

7 years agoVcoreid sanity checks in event code
Barret Rhoden [Sat, 17 Dec 2011 00:43:26 +0000 (16:43 -0800)]
Vcoreid sanity checks in event code

Very large vcoreid's could cause the kernel to find VCPD addresses
outside of procdata.  MAX_NUM_CPUS is what we use for MAX_NUM_VCORES
btw.  No one should want/need more vcores than that.  k/s/pmap.c has
checks built in to make sure procdata stays within its size too.

7 years agoRemoved dangling symlink
Barret Rhoden [Fri, 16 Dec 2011 01:20:54 +0000 (17:20 -0800)]
Removed dangling symlink

7 years agoCleans up preempt_pending helper functions
Barret Rhoden [Thu, 15 Dec 2011 00:41:32 +0000 (16:41 -0800)]
Cleans up preempt_pending helper functions

Don't call __check_preempt_pending() from places that can't handle a
noreturn.  Examples include inside event handlers, while processing an
ev_q (you'll miss messages), while holding locks, etc.  If a preempt is
pending, the vcore will yield and may never come back.  Next time it
runs, it'll be starting fresh from vcore_entry().

If needed, we can make versions of event handlers that can handle
responding to a preempt_pending, but those will need to be careful to
not ignore message queues and stuff like that.  One of the side effects
of not returning is that someone might be expecting you to process all
of your messages, etc.

7 years agosys_change_vcore can send CHECK_MSGS event
Barret Rhoden [Wed, 14 Dec 2011 21:51:55 +0000 (13:51 -0800)]
sys_change_vcore can send CHECK_MSGS event

When a vcore changes to another, and when that vcore has no need to
return (packed up its cur_uth, not holding locks, etc), then to deal
with it going offline, the process just needs to check its messages.

7 years agoPreemption events sent via SPAM, and not INDIR
Barret Rhoden [Wed, 14 Dec 2011 01:59:24 +0000 (17:59 -0800)]
Preemption events sent via SPAM, and not INDIR

In accordance with prophecy (aka, documentation from 'n' commits ago).

Note we are using the small ev_qs, which merely tell the kernel where to
send things.  In this case, it is to spam the messages to VCPD public
mboxes.

7 years agoEvent flag for spamming public messages (XCC)
Barret Rhoden [Wed, 14 Dec 2011 01:38:48 +0000 (17:38 -0800)]
Event flag for spamming public messages (XCC)

ev_qs can use EVENT_SPAM_PUBLIC to send a spammable message to some
vcore's public mbox.  This flag will honor VCORE_MUST_RUN.  We'll try to
spam ev_q->ev_vcore, or someother prescribed source of vcoreid (like
APPRO, for whatever the kernel thinks is appropriate, or ROUNDROBIN).

Cleaned up send_event() a bit too, esp regarding how we come up with the
vcoreid and the ev_mbox (SPAM_PUBLIC doesn't need to bother with an
ev_mbox).

Reinstall your kernel header(s).

7 years agoPreemption recovery handler
Barret Rhoden [Tue, 13 Dec 2011 23:25:59 +0000 (15:25 -0800)]
Preemption recovery handler

The handler is still a bit rough, and there are a couple nagging bugs
out there.

7 years agoUthread helper to copy a uthread's context
Barret Rhoden [Tue, 13 Dec 2011 23:15:00 +0000 (15:15 -0800)]
Uthread helper to copy a uthread's context

From the VCPD to the uthread, subject to where the uthread's flags say
its contexts are.

7 years agoUTHREAD_FPSAVED flag
Barret Rhoden [Tue, 13 Dec 2011 23:10:42 +0000 (15:10 -0800)]
UTHREAD_FPSAVED flag

Tracks whether or not the uthread's FP state is saved in it's uthread
struct, much like UTHREAD_SAVED.  It's a bit different, since we load
the FP state at different places.

In the future, we can (or you can!) set up some optimizations to only
save the FP state if it was used/needs to be saved.

7 years agoRemote mbox can deal with recursive calls (XCC)
Barret Rhoden [Tue, 13 Dec 2011 21:33:13 +0000 (13:33 -0800)]
Remote mbox can deal with recursive calls (XCC)

This handles cases where you are handling a remote vcpd mbox, and then
want to handle another remote mbox (which happens if the remote mbox got
a preemption message).  The way we handle all of the cases uses some
form of "tell our future self what to do".

I also moved the relevant code over to event.c, which might make it more
reusable for future event handlers.  Note that any event handler that
doesn't return needs to somehow deal with VCPD mboxes around the
no-return site.  We have a couple handlers for that.

Reinstall your kernel header(s).

7 years agosys_self_notify() now honors ev_type
Barret Rhoden [Sat, 10 Dec 2011 00:09:53 +0000 (16:09 -0800)]
sys_self_notify() now honors ev_type

Previously, if you didn't send a u_msg, we weren't sending the type.
The desired behavior of this half-assed syscall is to send either
ev_type with 0s for arguments, or send u_msg.

7 years agoEvent helper for detecting empty mboxes
Barret Rhoden [Fri, 9 Dec 2011 23:27:08 +0000 (15:27 -0800)]
Event helper for detecting empty mboxes

7 years agoBit messages are now flagged (XCC)
Barret Rhoden [Fri, 9 Dec 2011 23:12:26 +0000 (15:12 -0800)]
Bit messages are now flagged (XCC)

This saves a scan of the bitmap every time we check events or want to
know if an ev_mbox has messages - even if one of the event handlers
didn't return.

Reinstall your kernel headers.

7 years agosys_self_notify() takes a flag for private mboxes
Barret Rhoden [Fri, 9 Dec 2011 01:41:42 +0000 (17:41 -0800)]
sys_self_notify() takes a flag for private mboxes

Sending TRUE will send the message to the VCPD private mbox.  I'm not
100% on sys_self_notify like this - perhaps we'll take an ev_q in the
future.  But for now this works.

7 years agoRenames ridiculous sys_getcpuid call (XCC)
Barret Rhoden [Thu, 8 Dec 2011 00:50:45 +0000 (16:50 -0800)]
Renames ridiculous sys_getcpuid call (XCC)

You don't really need to call that, since you can check the vcoremap,
but we'll keep the call around for now (debugging).  But it's now called
getpcoreid, which is more clearly what it is.

Not like we need a syscall to do a cpuid.  Or to change the stack
pointer...  =P

Reinstall your kernel header (ros/bits/syscall.h).

7 years agox86: Detection for RDFSBASE and friends
Barret Rhoden [Thu, 8 Dec 2011 00:42:46 +0000 (16:42 -0800)]
x86: Detection for RDFSBASE and friends

These are new extensions that we'll eventually use to deal with the TLS
vulnerabilities that we have on x86 from exposing the LDT.

To do the detection, we needed to pass through a second uint32, which
some of the cpuid leaves require.

7 years agoFALLBACK logic -> spam_public_msg() (XCC)
Barret Rhoden [Wed, 7 Dec 2011 22:30:10 +0000 (14:30 -0800)]
FALLBACK logic -> spam_public_msg() (XCC)

The old logic behind the FALLBACK aspects of alert_vcore(), which was
used to make sure INDIRs made it to a (optionall running) vcore is now
more generic, and is callable for arbitrary ev_msgs, not just INDIRs.
INDIRs still benefit from this, and they call it at the bottom of
send_indir().  Other messages (e.g. preemption, in future patches) can
use it to get the same delivery guarantee: your message will get spammed
to vcores until we're sure at least one of them got it and will read it.

The VCORE_MUST_RUN flag is still supported.  It means that when
spamming, we pick vcores that must be running, compared to settling for
a vcore that will eventually get looked at (during preemption recovery).

Note that there is no way in this patch for userspace to access the
spam_public_msg().

Trivial change to the kernel header (ros/event.h) - userspace doesn't
use it yet, and might not ever.

7 years agoUthread support to handle remote public VCPD mbox
Barret Rhoden [Wed, 7 Dec 2011 22:24:22 +0000 (14:24 -0800)]
Uthread support to handle remote public VCPD mbox

Will be used by preemption.  We needed to jump back to vc_entry to avoid
recursing, etc.

7 years agoPublic VCPD mboxes (XCC)
Barret Rhoden [Mon, 5 Dec 2011 23:32:58 +0000 (15:32 -0800)]
Public VCPD mboxes (XCC)

Each vcore has two mboxes, one for public messages (meaning they can be
read by any vcore) and one for private (specific to that vcore only).
Both are checked by handle_events().  We need this because there are
situations where we will need to read another vcores messages
(preemption recovery) to make sure we get certain messages
(specifically, INDIRs and preemption notices) regardless of preemption,
yielding, etc.

Check the Documentation for more info.  We don't use these yet for much
(there's no ev_q flag, for instance), and preemptions still use INDIRs.
That'll change shortly.

Reinstall your kernel headers.

7 years agovcpd_of() helper for userspace
Barret Rhoden [Mon, 5 Dec 2011 19:27:32 +0000 (11:27 -0800)]
vcpd_of() helper for userspace

There are a few places I didn't change it yet; those are getting
concurrently modified in another commit.

Note I don't have a helper for the kernel.  For now, I want to be
explicit about which entry point into procdata we use (the user address
or the kernel address).

7 years agoUthread vc_entry will spin on STEALING
Barret Rhoden [Tue, 29 Nov 2011 23:52:33 +0000 (15:52 -0800)]
Uthread vc_entry will spin on STEALING

If for any reason STEALING is set, a vcore can't touch its
current_uthread.  2LSs don't need to worry about it; uthread code will
deal with it before calling out to a 2LS.  Preemption recovery code will
muck with this.

7 years ago2LS sched op: thread_paused()
Barret Rhoden [Tue, 29 Nov 2011 23:29:28 +0000 (15:29 -0800)]
2LS sched op: thread_paused()

This gets called when a uthread stopped due to some async activity
(unlike yield, which is caused by the uthread in some way).  Check out
the pth example for more details.

7 years agoUthread can handle clear_notif_pending
Barret Rhoden [Wed, 23 Nov 2011 01:31:00 +0000 (17:31 -0800)]
Uthread can handle clear_notif_pending

clear_notif_pending() might not return, and it might return and clear
your current_uthread.  The latter can happen if you service a preemption
of another vcore that was stuck in vc context and fail to change_to that
vcore (which happens if that vcore starts up for any reason).

So if we lose our current_uthread, we just restart the vcore.  We're
also careful to make sure we don't lose a *uthread if clear_notif
doesn't return.

In the process, I also made a little helper, since there's a lot of
common code between run_cur_uth and run_uth.  __run_cur_uth_raw() is
still a bit weird and different: enough so that I'll leave it alone.

7 years agoUthread flag tells us where the context is saved
Barret Rhoden [Sat, 19 Nov 2011 02:00:59 +0000 (18:00 -0800)]
Uthread flag tells us where the context is saved

So we know how to save it during preemption recovery.  The flag means
that the context for the uthread is in the utf.  If it isn't there, it's
in the VCPD notif trapframe (or will be there soon, in such a manner
that we won't steal the thread or handle other vcore's preemptions until
it is in the notif_tf).

7 years agoFixes sys_change_vcore() return path
Barret Rhoden [Mon, 14 Nov 2011 20:39:26 +0000 (12:39 -0800)]
Fixes sys_change_vcore() return path

Once we unlock, we could have the calling vcore start up remotely before
we get a chance to finish the syscall (writing the syscall struct).  If
the vcore had notifs disabled, it'll start up where it left off and wait
on the syscall finishing, which is fine.  However, if the vcore starts
from scratch on a remote core, nothing will ever wait on the sysc, and
we now could be writing into the stack at some random future date.

7 years agoVcore states for preemption recovery (XCC)
Barret Rhoden [Wed, 9 Nov 2011 23:12:01 +0000 (15:12 -0800)]
Vcore states for preemption recovery (XCC)

The kernel writes the states, and userspace will CAS with the kernel
whenever it needs to make decisions / sync on the flags.  I'll use this
more in the future.

Side note: having the kernel set the K_LOCK prevents userspace from
thinking a vcore wasn't preempted.  Ex: it receives a message, but
__preempt hasn't happened yet.  The preempt recovery handler will
(eventually) check/spin on the K_LOCK, which gets cleared once the vcore
is fully preempted.

Reinstall your kernel header(s).

7 years agoVcores always start in vcore context
Barret Rhoden [Wed, 9 Nov 2011 01:37:41 +0000 (17:37 -0800)]
Vcores always start in vcore context

Previously, after a preemption, the vcore would start whatever was
running when it was preempted: specifically, it could start a uthread.
Now, it'll always start in vcore context.  The 2LS will likely restart
the uthread right away.

We'll need this change to be able to steal uthreads from preempted
vcores (in future patches).  While the older style seemed reasonable for
programs written directly on the kernel, the 2LS now handles everything.

7 years agonotif_enabled -> notif_disabled (XCC)
Barret Rhoden [Wed, 9 Nov 2011 00:55:06 +0000 (16:55 -0800)]
notif_enabled -> notif_disabled (XCC)

The default state is now notifs enabled.  Vcores will still come up with
notifs disabled: the kernel will sort that out.  Its just that fresh
vcore preempt data won't need to have notifs manually enabled or
anything for the _S -> _M transition.

Reinstall your kernel header(s).

7 years agoClarifies/fixes some issues with __preempt and MCS
Barret Rhoden [Mon, 24 Oct 2011 18:00:08 +0000 (11:00 -0700)]
Clarifies/fixes some issues with __preempt and MCS

We need the wmb() in __preempt, which is racing with __map_vcore()
(among other things).  Basically, we need to make sure we don't give out
the vcore while cleaning up the vcore.  Once we __unmap_vcore(), we need
to never touch it again til it is mapped.

Likewise, the MCS-PDR code can quite easily see a situation where a core
is preempted but is still mapped.  The old assertion was mostly to catch
bugs, but that wasn't a "safe" check, since the preempting and unmapping
isn't atomic from the perspective of other cores.

7 years agoNo longer uses num_vcores() to determine _M (XCC)
Barret Rhoden [Tue, 18 Oct 2011 00:43:45 +0000 (17:43 -0700)]
No longer uses num_vcores() to determine _M (XCC)

We were using num_vcores() == 0 to determine if we're in _M mode or not.
This won't be true when we start sending bulk preempt messages, since
num_vcores() is 0 for an instant, which could trick some code to think
it is in _S mode and bypass some critical stuff.

Reinstall your kernel headers (procinfo.h).

7 years agovcore_request() no longer uses MCS locks
Barret Rhoden [Tue, 18 Oct 2011 00:21:19 +0000 (17:21 -0700)]
vcore_request() no longer uses MCS locks

All cores update a shared atomic, saying they want that many vcores.
One core will actually handle the process of prepping the vcores and
asking the kernel for them.

Note that the whole request/yield process and its effects on amt_wanted
and whatnot is rather jacked up.  Vcore code needs to be smarter about
how it interacts with amt_wanted, which will require some help from the
kernel, which I'll do in future patches.

7 years agoUthread blockon handles notif_disabled uthreads
Barret Rhoden [Thu, 13 Oct 2011 01:06:56 +0000 (18:06 -0700)]
Uthread blockon handles notif_disabled uthreads

The in_vcore_context() check tests TLS, not whether or not notifs are
disabled.  It is the latter we care about more.  We need to check
DONT_MIGRATE before checking if notifs are disabled (vcoreid), and any
code that does have DONT_MIGRATE set *when making a syscall* needs to
have notifs disabled.  I don't explicitly check for this, since you have
to set DONT_MIGRATE to be sure about your vcoreid.

7 years agoMore thoroughly detect preemptions
Barret Rhoden [Thu, 13 Oct 2011 00:50:23 +0000 (17:50 -0700)]
More thoroughly detect preemptions

MCS-PDR code checks for preemptions via preempt_tf_valid.  If you don't
you can accidentally think a yielded vcore is preempted.  Either way, it
is unmapped.  In the future, it'll be safe to restart them, but right
now we don't handle preemption messages, so processes can run into
issues.  Also, you don't really want to restart a yielded vcore.  Next
time you spin in the MCS code, you will (hopefully!) get a different
vcore (reread lockholder, etc).

Also, we were a bit sloppy about the use of preempt_tf_valid.  It's
actually an ancient seq_ctr instead of a bool.  The 2 year old reason
for that was to help us detect changes to the preempt tf for remote
recovery, but I have a feeling it might not be strong enough.

7 years agoPthreads now uses mcs_pdr locks
Barret Rhoden [Wed, 12 Oct 2011 23:24:20 +0000 (16:24 -0700)]
Pthreads now uses mcs_pdr locks

Instead of the old notif_safe MCS ones.  Note that the MCS-PDR locks are
notif_safe, and can be called from uthread context.

For those curious, pthread code has functions that lock that are called
from uthread context and from vcore context.  Specifically,
uthread_runnable/pth_thread_runnable can come from
uthread_init/pthread_create, which is uthread context, and
restart_thread, which is vcore context.  Plus, the pth_sched_entry
hammers the same runqueue lock in vcore context.

7 years agoproc_change_to_vcore() races fixed
Barret Rhoden [Wed, 12 Oct 2011 23:21:32 +0000 (16:21 -0700)]
proc_change_to_vcore() races fixed

This function had the same sorts of races as proc_yield(), namely that
your calling vcore could have been __preempted, have a preempt_served,
be DYING, etc.

Also saves the FP state and a couple other minor things.

7 years agoFixes race and rewrites proc_yield()
Barret Rhoden [Wed, 12 Oct 2011 21:30:10 +0000 (14:30 -0700)]
Fixes race and rewrites proc_yield()

The race was with concurrent __preempts.  preempt_served would get
turned off and we'd be unmapped.  We needed to check for being unmapped
with irqs disabled.

preempt_served serves as a "preemption is on the way, but hasn't hit
yet".  In this case, we've been removed from the online list and just
need to return and take the preemption.  A process might see this as
yield failing, either immediately or when the vcore gets restarted.

A few notes on proc_yield, and the unfortunate fact that we lock in it
(making it a pain for scalability):

1) Yield needs to leave the core, just like __death.  unmap, abandon,
etc.

2) It is safe to do one unmap without the lock, but only if you were
told to by the lockholder (which is what __preempt and __death do).
Granting new ones requires the lock.  Other than in __preempt and
__death, you can't trust reading the vcoremap to get your vcoreid
without the lock, since you could see the result of a take_core then a
give_core to different a vcore.  This is probably true.

3) Adding the pcore to the idlecoremap involves locking too (though not
the proc_lock);

4) Yield needs to not conflict with KMSGs.

5) Yield needs to not miss a notif_pending (playing shmem games with the
lists and __alert_vcore()

6) Lacking any remote __preempt/__death/__myield, yield needs to remove
its vcore from the online_list, which requires locking.

7 years agoUCQs now use mcs_pdr_locks (XCC)
Barret Rhoden [Wed, 12 Oct 2011 01:12:22 +0000 (18:12 -0700)]
UCQs now use mcs_pdr_locks (XCC)

I'm using the memory safe locks for now.  You can get away with unsafe
versions if the storage for them never gets freed (and we'd need some
sanity checks in __ensure_qnode_runs()), though I'm not 100% on whether
or not uthread code will ever call ucq code, and as of right now,
uthread stacks get freed (2LS decision).

The downside to this is that our MCS-PDR locks use more memory, and that
memory was not as likely to be in the cache as the stack.

Reinstall your kernel headers (ucq.h).

7 years agoFixes ext2 RAM block device linking
Barret Rhoden [Thu, 15 Dec 2011 22:32:26 +0000 (14:32 -0800)]
Fixes ext2 RAM block device linking

Same deal as with 5aac42b0631a8, we need to convert it to a .o to link
it in.  It's a bit crappy, since we have to process another large file,
but it works for now.

7 years agoFixes excessive make realcleans
Barret Rhoden [Thu, 15 Dec 2011 21:38:22 +0000 (13:38 -0800)]
Fixes excessive make realcleans

Since b8738ad0, every time you make, you'd do a make realclean (at least
on x86), since the $@ wasn't changed when the target had "real-" added
to it.

7 years agoFixes gcc 4.6.1 incompatibility with old x86 asm
Barret Rhoden [Thu, 15 Dec 2011 21:05:36 +0000 (13:05 -0800)]
Fixes gcc 4.6.1 incompatibility with old x86 asm

4.6.1 didn't like the old version (couldn't handle the possibility of
"m", perhaps rightfully so).

Did anyone actually build the kernel on x86 with the new compiler, or
was it just my system that couldn't handle it?

7 years agoFixes binutils patch: Hammertime!
Barret Rhoden [Thu, 15 Dec 2011 19:11:52 +0000 (11:11 -0800)]
Fixes binutils patch: Hammertime!

Lots of systems have problems building some versions of binutils due to
the weirdness around RPATH_ENVVAR.  No idea why binutils does that crap.
We've adopted the same patch that Gentoo uses for the version of
binutils they distribute.

Hammertime!!

7 years agoFix xcc's "make patches"
Andrew Waterman [Thu, 15 Dec 2011 02:49:25 +0000 (18:49 -0800)]
Fix xcc's "make patches"

8 years agoadd getrlimit64 stub
Your Name [Sat, 12 Nov 2011 08:05:21 +0000 (00:05 -0800)]
add getrlimit64 stub

Necessary to link busybox on RISC-V.  The problem is
actually that the generic version doesn't libc_hidden_def
itself, so the exported symbol name was mangled.

8 years agoFixed bug in RISC-V env_user_mem_free
Your Name [Sat, 12 Nov 2011 08:04:39 +0000 (00:04 -0800)]
Fixed bug in RISC-V env_user_mem_free

It was rounding up to the largest page size, causing
procinfo/procdata to be freed on sys_exec.

8 years agoRISC-V compiler port configure script changes
Andrew Waterman [Fri, 11 Nov 2011 14:09:26 +0000 (06:09 -0800)]
RISC-V compiler port configure script changes

I had to change the RISC-V compiler port a bit to
maintain backwards compatibility with our generic
Newlib/ELF target.  This actually simplified the
configure script changes for RISC-V on ROS.

The commit is large because I've now put the RISC-V
cross-compiler in its own git repo, and I'm using
git diff to generate the patch files, and the slight
formatting change makes for a large apparent change.

8 years agoFixed RISC-V page fault handling
Andrew Waterman [Fri, 11 Nov 2011 09:14:40 +0000 (01:14 -0800)]
Fixed RISC-V page fault handling

The current tf wasn't being set.

8 years agoChanges to RISC-V supervisor mode
Andrew Waterman [Fri, 11 Nov 2011 08:32:22 +0000 (00:32 -0800)]
Changes to RISC-V supervisor mode

See commit comments in ISA simulator for details

8 years agoMiscellaneous RISC-V compiler updates
Andrew Waterman [Fri, 11 Nov 2011 08:31:50 +0000 (00:31 -0800)]
Miscellaneous RISC-V compiler updates

8 years agoDynamic linking now works on RISC-V
Andrew Waterman [Tue, 8 Nov 2011 09:39:13 +0000 (01:39 -0800)]
Dynamic linking now works on RISC-V

The spurious invalid dynamic relocations within ld.so
were caused by our errno.c using TLS for errno within
the RTLD.  Instead, we should use a global errno then.