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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 22.08.16 at 19:30, <andrew.cooper3@xxxxxxxxxx> wrote:
> 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.

No, because PV Linux doesn't use native CPUID. We clearly should
not hide OSXSAVE in the PV variant (and your earlier series did take
great care to avoid that).

Jan

> 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