A couple more things:
> From 4d4c1e1c2f91da37063773c32433f9abee07b559 Mon Sep 17 00:00:00 2001
> From: Michael Taufen <[email protected]>
> Date: Mon, 22 Feb 2016 14:11:37 -0800
> Subject: Extended state data structures
This commit changes a kernel header, so you need to put (XCC) in the
commit title and tell people a little about what is changing and what to
do.
Based on the nature of the change (changing the size of a trapframe) you
also need tell people to reinstall their kernel headers and rebuild
userspace. I usually do this like so:
Reinstall your kernel headers and rebuild all user apps.
> From 44fc3cbbfe39b3f48aa9504ee56c4f824b5b020a Mon Sep 17 00:00:00 2001
> From: Michael Taufen <[email protected]>
> Date: Mon, 22 Feb 2016 14:55:52 -0800
> Subject: fp state save, restore, and error handling
> diff --git a/kern/include/trap.h b/kern/include/trap.h
> index 9f1346904d18..37f3283d214c 100644
> --- a/kern/include/trap.h
> +++ b/kern/include/trap.h
> @@ -26,7 +26,7 @@ void set_core_timer(uint32_t usec, bool periodic);
> void timer_interrupt(struct hw_trapframe *hw_tf, void *data);
>
> extern inline void save_fp_state(struct ancillary_state *silly);
> -extern inline void restore_fp_state(struct ancillary_state *silly);
> +extern inline int restore_fp_state(struct ancillary_state *silly);
Minor thing I missed the first time: this is changing the Akaros-wide
header for restore_fp_state(). Thinking about it a bit, the ability to
fail on that is an x86-specific thing. So we probably can take this
logic (from process.c):
if (restore_fp_state(&vcpd->preempt_anc)) {
printk("Error restoring fp state! Likely a bad
ancillary_state at vcpd's preempt_anc\n");
init_fp_state();
and push it inside restore_fp_state().
The alternative is to change RISC-V's restore_fp_state to return an int
as well. Thinking about doing changing RISC-V is what made me realize
that this is just an artifact of x86, and probably doesn't need to
taint the rest of the OS. I'm open to either approach though (pushing
the logic into restore_fp_state() or changing RISC-V to potentially
fail).
Also, when I run the latest VM from last_known_good (9e4eebc745e0
("Merge pull request #8 from mtaufen/last_known_good")), I get an
unending spew of this:
IO @ 0xffffffff81302f51
unknown IO 0x1302f51 e6 43e6
Do you get that too? Are you running from vmrunkernel in the Akaros
repo?
Barret
--
You received this message because you are subscribed to the Google Groups
"Akaros" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.
