hi Rusty,

On Tue, Jun 17, 2008 at 10:34:23PM -0700, Rusty Russell wrote:
quoted text
>    Firstly, thanks for figuring this out.  But math_state_restore() has nasty
> semantics now.  Currently lguest will work, because no code path following
> this call relies on being on the same CPU.
> 
> So, this patch is fine, but I wonder if I should just be forcing fpu
> allocation earlier for lguest tasks, so I can avoid this altogether?

Even with force fpu allocation, we need these fixes(except for the SYSENTER
hunk)

Just to clarify, dynamic fpu allocation didn't create these problems.
Some of these problems were there before aswell, and would show up as
fpu corruption for some of the tasks inside the lguest. With the
dynamic fpu allocation, it showed up as host kernel oops.

In future, if lguest driver code ever has a code path which relies
on running on the same cpu after math_state_restore(), yes they
can force allocate, by doing early math_state_restore() before
the guest starts.

But the current usage of lguest_set_ts() is clearly broken and violates
certain behavior expected by the fpu context switch handling routines.

thanks,
suresh
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/