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

[Haitao Shan <maillists.shan@xxxxxxxxx>]

I once considered this problem, too. Originally, I suppose I can use
CR4 switching when entering/leaving PV guest, as what HW is doing for
us in VMX. But I suspect this will bring a lot of overhead.
Later I picked the current implementation, hoping guest applications
can have a check on XCR0 first before it uses extended states. And
according to spec, in order to use extend states, XCR0 must be set,
but this is a ring 0 instruction only.

Shan Haitao

2010/10/28 Jan Beulich <JBeulich@xxxxxxxxxx>:
>>>> On 28.10.10 at 09:55, Haitao Shan <maillists.shan@xxxxxxxxx> wrote:
>> 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.
>
> Ah, okay. There's one problem with this, however - a pv domain the
> kernel of which doesn't support xsave would still see CPUID report
> the OSXSAVE bit set, and hence applications could be lead to
> believe they can use the wider registers. I realize this also puts
> under question our model of having the kernel look at CPUID's
> OSXSAVE bit, but that could possibly be dealt with by having
> pv_cpuid() (and perhaps xc_cpuid_pv_policy()) set the bit in case
> Xen supports xsave.
>
> Jan
>
>

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