Re: [Xen-devel] [PATCH 0/3 v2] XSAVE/XRSTOR fixes and enhancements

[Weidong Han <weidong.han@xxxxxxxxx>]

Keir Fraser wrote:
> On 31/08/2010 15:52, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
>
>   
> > Change logs from v1 -> v2:
> > Due to not guarantee backward compatibility, drop the guest save/restore patch
> > here. Will re-implement it later. In addition, split the original fix frozen
> > states patch into XSAVE/XRSTOR cleanup patch and fix frozen state patch.
> >
> > Patch 1/3: XSAVE/XRSTOR: some cleanups
> > Replace xfeature_low and xfeature_high with a u64 variable xfeature_mask.
> > In structure hvm_vcpu, rename xfeature_mask to xcr0
> > Provide EDX:EAX with all bits set to 1 for XSAVE and XRSTOR as spec
> > recommends.
> >
> > Patch 2/3: Fix frozen states
> > If a guest sets a state and dirties the state, but later temporarily clears
> > the state, and at this time if this vcpu is scheduled out, then other vcpus
> > may corrupt the state before the vcpu is scheduled in again, thus the state
> > cannot be restored correctly. To solve this issue, this patch save/restore all
> > states unconditionally on vcpu context switch.
> >     
> Performance overhead of this fix? Is there no other lazy save technique that
> can work?
>   
I think the cost of set_xcr0 which just changes some bits in XCR0 
register should be little.  I don't have any optimization for it now.
>   
> > Patch 3/3. Enable guest AVX
> > This patch enables Intel(R) Advanced Vector Extension (AVX) for guest.
> >     
> If we enable this but don't implement save/restore then don't guests lose
> state across s/r with unpredictable results?
>   
Yes. As I said in another email, actually it already breaks hvm guests 
save/restore on platforms which supports XSAVE/XRSTOR.
Regards,
Weidong
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel