Re: XSAVES in GET_SUPPORTED_CPUID (was Re: [Qemu-devel] [PATCH] target-i386: add Skylake-Client cpu mode)

[Dave Hansen <dave.hansen@intel.com>]

On 05/03/2016 11:23 AM, Eduardo Habkost wrote:
> On Tue, May 03, 2016 at 10:53:43AM -0700, Dave Hansen wrote:
>> On 05/03/2016 10:44 AM, Xiao Guangrong wrote:
>>>>> This is the reason why setup_clear_cpu_cap(X86_FEATURE_XSAVES)
>>>>> introduced by commit e88221c50
>>>>> caused XSAVES unreported by KVM.
>>>>
>>>> So, is this the right behavior, or KVM can support exposing
>>>> XSAVES to guests even if the cpu_cap bit is cleared? I don't know
>>>> if exposing XSAVES to KVM guests depend on reworking kernel xsave
>>>> code or not.
>>>
>>> I think current behavior is right. KVM uses kernel's APIs to
>>> save/restore FPU context that may
>>> cause XSAVE not properly switched if XSAVES is used in VM but host does
>>> not see it.
>>
>> I don't think this is a correct statement.
>>
>> The guest's use of XSAVES is completely independent of what instructions
>> the host (kernel) uses for its xsave buffer.
>>
>> For instance, just because the kernel doesn't use XSAVES to context
>> switch Processor Trace, it does not make Processor Trace unusable to a
>> guest.  Guests are still free to do what they want with it (including
>> using XSAVES for its MSRs too btw...).
>>
> 
> In this case, is it better to replace the
> setup_clear_cpu_cap(X86_FEATURE_XSAVES) quirk with some other
> workaround that won't affect GET_SUPPORTED_CPUID, or should we
> make GET_SUPPORTED_CPUID ignore cpu_cap in the case of
> X86_FEATURE_XSAVES?

I think we should introduce a X86_FEATURE_ in word 3 (the Linux-defined
ones) that says whether Linux is *using* XSAVES for its FPU buffers.

Then make sure that we leave X86_FEATURE_XSAVES alone so that it
accurately represents what the _hardware_ supports.  We might even want
to change the name of X86_FEATURE_XSAVES so we don't confuse it with the
software bit.