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

[Shuai Ruan <shuai.ruan@xxxxxxxxxxxxxxx>]

On Fri, Feb 26, 2016 at 01:42:35AM -0700, Jan Beulich wrote:
> >>> On 26.02.16 at 08:41, <shuai.ruan@xxxxxxxxxxxxxxx> wrote:
> > On Wed, Feb 24, 2016 at 02:16:38AM -0700, Jan Beulich wrote:
> >> >> 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.
> 
Thanks. 

Ok , I will do the performace test. And can you suggest me some 
workload/benchmark 
can be used here to the xsave related performance test ?


Other thing is from the text above, I guess that the best way to solve xsave[cs]
problem is:
1. use xsaveopt instead of xsave[cs] nowdays.
2. use xsaves whenever a component can only be saved that way( when some
   supervised components are supported in xen).
3. no xsavec support.
4. xsavec/xsaves feature will expose guest os if point 2 is ok.

If the above 4 points are ok to you, then I will write a patch to do
this.

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

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