[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] XSAVES in GET_SUPPORTED_CPUID (was Re: [PATCH] target-i

From: Dave Hansen
Subject: Re: [Qemu-devel] XSAVES in GET_SUPPORTED_CPUID (was Re: [PATCH] target-i386: add Skylake-Client cpu mode)
Date: Tue, 3 May 2016 11:29:37 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]