On Sun, Dec 2, 2018 at 2:07 PM Nadav Har'El <[email protected]> wrote:

>
> 2. If this was a voluntary context switch, the scheduler returns into
> whatever function which called it (sleep(), read(), etc.) and that returns
> to. The floating point state was never saved (it doesn't need to be,
> because a function was called) but, on return, it was never restored. It
> just gets a copy of whatever junk was there from the previous thread or OSv
> code that ran. The junk st0..st7 registers are fine - the caller cannot
> count on anything in there too. But the control registers might now have
> junk as well, and that OSv does have to restore, and that it does since
> commit 0959f20863b119c5ca7d1e663bc22e6329814386. However, we will never
> restore the floating point *status* word (FSW). So if one thread was
> interrupted with a full fp stack, another thread we switch to might be
> returned-to with a full stack.
>
> *You can try adding an FNINIT in arch-switch.hh *before*
> processor::fldcw(fpucw) and see if it fixes anything.*
>

I opened https://github.com/cloudius-systems/osv/issues/1020 about this.

I wouldn't want to fix this without first proving it is needed. Either
(hopefully!) it (i.e., adding FNINIT (or maybe FINIT?) and EMMS in the
switch_to() code) will help in the bug you can reproduce, or creating a new
reproducer - e.g., two user-space threads, one filling the FPU stack with
garbage and the other trying a loop of normal FPU work and seeing if
something fails.

Nadav.

-- 
You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to