|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [Patch 2/4] Refining Xsave/Xrestore support
In my patch, if processor supports CR4.OSXSAVE, Xen will enable it and
won't clear it as long as we are in ROOT mode.
Shan Haitao
2010/10/28 Jan Beulich <JBeulich@xxxxxxxxxx>:
>>>> On 28.10.10 at 04:57, Haitao Shan <maillists.shan@xxxxxxxxx> wrote:
>> 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.
>
> Hmm, in our kernels we check the OSXSAVE feature bit instead,
> expecting (just like for FXSAVE) the hypervisor to enable the bit
> in CR4 when it supports the feature.
>
> I think a mechanism needs to be found in the hypervisor that
> accommodates both current pv-ops and current forward port
> kernels' behaviors.
>
> Jan
>
>> 2010/10/28 Jeremy Fitzhardinge <jeremy@xxxxxxxx>:
>>> 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
>>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|