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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/08/16 19:07, Andrew Cooper wrote:
> On 19/08/16 18:09, Andrew Cooper wrote:
>> On 19/08/16 13:53, 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, whereas prior to
>>> this patch
>>> - on Intel guest user mode always saw the flag clear,
>>> - on AMD guest user mode saw the flag set even when the guest kernel
>>>   didn't enable use of XSAVE/XRSTOR.
>>> Fold in the guest view of CR4.OSXSAVE when setting the levelling MSRs,
>>> just like we do in other CPUID handling.
>>>
>>> To make guest CR4 changes immediately visible via CPUID, also invoke
>>> ctxt_switch_levelling() from the CR4 write path.

I was just putting together a patch series to make these changes in a
more consistent manor, and have found a spanner in the works.

Hiding Xen's view of OSXSAVE from a guests native cpuid will break
Linux, because of the pile of hacks making up the current PV XSAVE support.

Some PV guests needs to see OSXSAVE in native CPUID before they will
consider trying to use xsetbv.  I realise I have completely broken this
on Intel following the mistake in determining how the MSR masks
functioned, but seeing the value from CR4 of next will be no better.

Our choices are:
1) Always expose Xen's OSXSAVE, even to guest userspace
2) Context switch the MSRs even on guest userspace/kernel context switch.

The latter would allow us to expose Xen's OSXSAVE to guest kernels, but
expose guest kernels' OSXSAVE to guest userspace.  However, given the
number of ways for a guest kernel to context switch back to guest
userspace without Xen's interaction, we can't reliably provide an
architectural view to guest userspace.

Option 1 is the easiest patch, and least overhead.

~Andrew

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