Re: [Xen-devel] XSAVE flavors

[Shuai Ruan <shuai.ruan@xxxxxxxxxxxxxxx>]

On Thu, Feb 04, 2016 at 01:51:34AM -0700, Jan Beulich wrote:
> >> >> 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. 
> 
> I don't think that'll suffice, as it won't deal with the lazy XSAVE[SC]
> possibly overwriting data written by the non-lazy one. See the
> effectively three different values returned by vcpu_xsave_mask()
> (the fourth one is impossible since the function won't ever get
> called with both v->fpu_dirtied and v->arch.nonlazy_xstate_used
> clear).
Oh, Yes, Thanks.
The way I think to solve the problem is:
if v->fpu_dirtied is clear and v->arch.nonlazy_xstate_used is set,  
vcpu_xsave_mask will return XSTATE_ALL (only if xsave[sc] is support).
But this will do some overhead save.
> _______________________________________________
> 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