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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 23/08/16 10:41, Jan Beulich wrote:
>>>> On 23.08.16 at 11:24, <andrew.cooper3@citrix.com> wrote:
>> On 23/08/16 10:00, Jan Beulich wrote:
>>>>>> On 22.08.16 at 19:30, <andrew.cooper3@citrix.com> 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).
>> Where? There is no distinction for OSXSAVE.
>>
>> The only place in pv_cpuid() which distinguishes native vs emulated
>> cpuid is the X86_FEATURE_MONITOR handling.
>>
>> We distinguish kernel and userspace quite a lot, so the compatibility
>> breakages are only visible to the kernel.
> That's actually the part I meant.

I am sorry, but I now have no idea what you are referring to.  We can't
reasonably do a kernel/userspace split with masking, because would
become substantially higher overhead, and Xen isn't necessarily involved
in the context switch back to userspace.

~Andrew

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