Re: [Xen-devel] [PATCH] x86/PV: don't hide CPUID.OSXSAVE from user mode

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.08.16 at 17:41, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 16/08/16 16:20, Jan Beulich wrote:
>> User mode code generally cannot be expected to invoke the PV-enabled
>> CPUID Xen supports, and prior to the CPUID levelling changes for 4.7
>> (as well as even nowadays on levelling incapable hardware) such CPUID
>> invocations actually saw the host CR4.OSXSAVE value. Fold in the guest
>> view of CR4.OSXSAVE when setting the levelling MSRs, just like we do
>> in other CPUID handling.
> 
> How does this work?  The OSXSAVE is a fast-forwarded bit, not a regular bit.
> 
> There is nothing you can do to control it on Intel, as the MSRs are
> strictly and AND mask, applied before OSXSAVE and APIC are fast
> forwarded from real hardware state.

Considering that the change works (and things didn't work before) I
assume the AND-ing happens after the fast forwarding.

> On AMD, you can force it to zero by clearing the OSXSAVE bit, but you
> can never cause it to appear set if Xen has it cleared in CR4.

We don't allow guests to use XSAVE (and hence set the bit in CR4) if
we don't enable it ourselves. Hence if it's off in Xen, it'll be off
everywhere else (and that's what we want); i.e. in the consideration
of how this works, please assume CR4.OSXSAVE=1 for the raw
hardware reg.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel