[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 10:53:43 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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...).

reply via email to

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