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

[Weidong Han <weidong.han@intel.com>]

Keir Fraser wrote:
> On 31/08/2010 15:52, "Han, Weidong" <weidong.han@intel.com> 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
>
>
>
>