Re: [Xen-devel] [PATCH 2/3] x86/xsaves: fix overwriting between non-lazy/lazy xsave[sc]

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 26.02.16 at 08:41, <shuai.ruan@xxxxxxxxxxxxxxx> wrote:
> On Wed, Feb 24, 2016 at 02:16:38AM -0700, Jan Beulich wrote:
>> >> > --- a/xen/arch/x86/i387.c
>> >> > +++ b/xen/arch/x86/i387.c
>> >> > @@ -118,7 +118,7 @@ static inline uint64_t vcpu_xsave_mask(const struct 
>> >> > vcpu *v)
>> >> >      if ( v->fpu_dirtied )
>> >> >          return v->arch.nonlazy_xstate_used ? XSTATE_ALL : XSTATE_LAZY;
>> >> >  
>> >> > -    return v->arch.nonlazy_xstate_used ? XSTATE_NONLAZY : 0;
>> >> > +    return ( cpu_has_xsaves || cpu_has_xsavec ) ? XSTATE_ALL : 
>> >> > XSTATE_NONLAZY;
>> >> >  }
>> >> 
>> >> The description lacks any mention of the performance impact,
>> >> and what investigation was done to find ways to perhaps
>> >> overcome this. For example, regardless of cpu_has_xsaves,
>> >> do we really always need to _use_ XSAVES?
>> >> 
>> > Currently no supervisor xstates is enabled in xen or even in
>> > guest os. Using xsaves is a little ahead (xsavec may used).  
>> > xsavec may also cause overwriting problem like xsaves.
>> > I will add performance impact in the description. 
>> > I am still thinking of a better way to overcome the overhead xsave
>> > (But have not get a better solution yet).
>> 
>> I was thinking that taking into consideration the features a guest
>> has ever used (i.e. v->arch.xcr0_accum) to decide which variant
>> to use may be a worthwhile avenue to explore.
>> 
> Oh, Thanks for your suggestion.
> You mean when (v->arch.xcr0_accum & (XSTATE_LAZY & ~XSTATE_FP_SSE)) return 
> false,
> we can return XSTATE_NONLAZY in vcpu_xsave_mask when using xsave[cs]
> otherwise return XSTATE_ALL.
> It means we can save the area safely, if the guest has ever use 
> XSTATE_NONLAZY | XSTATE_FP_SSE only. 

That's one step in the right direction. But the main difference
between XSAVE/XSAVEOPT and XSAVEC/XSAVES is that the former
can be used incrementally, while the latter can't. And I highly
doubt the modified optimization the latter two support will kick in
very often, since there's quite good a chance that the guest
itself executed another one of these between two of our instances.
Which to me means it should at least be investigated whether using
XSAVEOPT in favor of XSAVEC wouldn't produce better performance,
and whether XSAVES wouldn't better be used only if the guest uses
a component which can only be saved that way.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel