[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: Eduardo Habkost
Subject: Re: [Qemu-devel] XSAVES in GET_SUPPORTED_CPUID (was Re: [PATCH] target-i386: add Skylake-Client cpu mode)
Date: Tue, 3 May 2016 15:23:52 -0300
User-agent: Mutt/1.5.24 (2015-08-30)

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


reply via email to

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