Re: [Patch 2/4] Refining Xsave/Xrestore support

[Jeremy Fitzhardinge <jeremy@goop.org>]

 On 10/28/2010 05:57 PM, Haitao Shan wrote:
> Then what about the approach that Jan uses in 2.6.27 tree, which is
> reading CPUID-OSXSAVE? If supported, Xen will always set CR4.OSXSAVE.

Sure, if CR4.OSXSAVE is set iff xsave is available, then it should work
fine if we test that.

    J

> Shan Haitao
>
> 2010/10/29 Jeremy Fitzhardinge <jeremy@goop.org>:
>>  On 10/27/2010 07:57 PM, Haitao Shan wrote:
>>> Hi, Jeremy,
>>>
>>> My approach is based an old PV-OPS kernel source. Kernel tries to set
>>> CR4.OSXSAVE and read it back to determine whether Xsave is actually
>>> available.
>>> Could you still use that?
>> No, because some older versions of Xen kill the domain when they try to
>> set unknown bits in CR4.
>>
>>    J
>>
>>> Shan Haitao
>>>
>>> 2010/10/28 Jeremy Fitzhardinge <jeremy@goop.org>:
>>>>  On 10/27/2010 12:04 AM, Haitao Shan wrote:
>>>>> Hi, Keir,
>>>>>
>>>>> This is patch #2, which adds PV guest Xsave support.
>>>> How does a PV guest know whether Xsave support is available?  Previous
>>>> versions of Xen left the xsave cpu feature flag set even though xsave
>>>> wasn't usable by the domain, so I had to forceably mask it from the
>>>> cpuid features within the domain.  Given that a PV domain can't rely on
>>>> X86_FEATURE_XSAVE, how can it tell that the feature is actually usable?
>>>>
>>>> Thanks,
>>>>    J
>>>>
>>