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? -- Eduardo
