[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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


On 05/05/2011 02:13 AM, Jan Beulich wrote:
On 04.05.11 at 18:33, Wei Huang<wei.huang2@xxxxxxx>  wrote:
Checking whether there is a non-lazy state to save is architectural
specific and very messy. For instance, we need to read LWP_CBADDR to
confirm LWP's dirty state. This MSR is AMD specific and we don't want to
add it here. Plus reading data from LWP_CBADDR MSR might be as expensive
as clts/stts.

My previous email showed that the overhead with LWP is around 1%-2% of
__context_switch(). For non lwp-capable CPU, this overhead should be
much smaller (only clts and stts) because xfeature_mask[LWP] is 0.
I wasn't talking about determining whether LWP state is dirty, but
much rather about LWP not being in use at all.

Yes, clts() and stts() don't have to called every time. How about this one?

/* Restore FPU state whenever VCPU is schduled in. */
void vcpu_restore_fpu_eager(struct vcpu *v)

      /* save the nonlazy extended state which is not tracked by CR0.TS bit */
      if ( xsave_enabled(v) )
          /* Avoid recursion */
          fpu_xrstor(v, XSTATE_NONLAZY);
That's certainly better, but I'd still like to see the xsave_enabled()
check to be replaced by some form of lwp_enabled() or
lazy_xsave_needed() or some such (which will at once exclude all
pv guests until you care to add support for them).


Xen-devel mailing list

Attachment: nonlazy_dirty.txt
Description: nonlazy_dirty.txt

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.