Re: XSAVE flavors

[Shuai Ruan <shuai.ruan@linux.intel.com>]

On Tue, Feb 02, 2016 at 02:42:38AM -0700, Jan Beulich wrote:
> >> > With this another question then is whether, when both XSAVEC
> >> > and XSAVEOPT are available, it is indeed always better to use
> >> > XSAVEC (as the code is doing after your enabling).
> > Yes.
> > But current no machine only support xsavec not support xsaves.  
> > I enable xsavec for "xsavec is a feature".
> 
> But this shouldn't preclude the code being in reasonable shape
> also for the case where a CPU has XSAVEC but no XSAVES. The
> more that right now we don't really need XSAVES (since we don't
> yet allow any bit to get set in XSS).
> 
Actually, when I enable xsaves/xsavec, I have put xsavec into
consideration. If xsavec is used we also need to guarntee that xcomp_bv 
never has any bits clear which are set in xstate_bv and the compaction
bit is set. 

Those guarntee and xsavec specific code in my patch is always behind "if( cpu_has_xsavec )" 
or " if ( cpu_has_xsaves || cpu_has_xsavec )".
Please remind me if there is some other things I am not aware.

> >> And I'm afraid there's yet one more issue: If my reading of the
> >> SDM is right, then the offsets at which components get saved
> >> by XSAVEC / XSAVES aren't fixed, but depend on RFBM (as that's
> >> what gets stored into xcomp_bv[62:0]). xstate_comp_offsets[],
> >> otoh, gets computed based on all available features, irrespective
> >> of vcpu_xsave_mask() returning four different values depending
> >> on current guest state. I can't see how get_xsave_addr() can
> >> work correctly without honoring xcomp_bv. Nor can I convince
> >> myself that state can't get corrupted / lost, e.g. when a save
> >> with v->fpu_dirtied set is followed by one with v->fpu_dirtied
> >> clear.
> >> 
> >> Am I misunderstanding what the SDM writes?
> >> 
> > Yes. you are right. This is a issue. I will find a way to solve
> > this.
> 
> Thanks.

For xstate_comp_offsets is only used in get_xsave_addr when performing migration. 
I intend to recaculte xstate_comp_offsets based on the vcpu->arch.xsavec_area.save_hdr.xcomp_bv 
before get_xsave_addr is called. 

The patch will be sent out after Chinese New Year holiday.

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