>>> 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
|
Home