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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
