Re: [Xen-devel] Re: [PATCH] FPU LWP 6/8: create lazy and non-lazy FPU restore functions

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> On 05.05.11 at 23:41, Wei Huang <wei.huang2@xxxxxxx> wrote:
> Hi Jan,
> 
> If we want to make LWP restore optional in vcpu_restore_fpu_eager(), we 
> have to change vcpu_save_fpu() as well. Otherwise, the extended state 
> will become inconsistent for non-LWP VCPUs (because save and restore is 
> asymmetric). There are two approaches:
> 
> 1. In vcpu_save_fpu(), clean physical CPU's extended state for VCPU 
> which is being scheduled in. This prevents messy states from causing 
> problems. The disadvantage is the cleaning cost, which would out-weight 
> the benefits.

Cleaning cost? Wasn't it that one can express to default-initialize
fields during xrstor (which, if indeed expensive, you'd want to trigger
only if you know the physical CPU's state is dirty, i.e. in this case
requiring a per-CPU variable that gets evaluated and updated on
context restore).

> 2. Add a new variable in VCPU to track whether nonlazy state is dirty. I 
> think this is better. See the attached file.
> 
> Let me know if it is what you want. After that, I will re-spin the patches.

Yes, this looks like what I meant. Two suggestions: The new field's
name (nonlazy_xstate_dirty) would perhaps better be something
like nonlazy_xstate_used, so that name and use are in sync. And
the check in vcpu_restore_fpu_eager() probably doesn't need to
re-evaluate xsave_enabled(v), since the flag can't get set without
this (if you absolutely want to, put in an ASSERT() to this effect).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel