From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axf5Q-0006Xl-0O for qemu-devel@nongnu.org; Tue, 03 May 2016 14:30:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axf5E-0001sU-9J for qemu-devel@nongnu.org; Tue, 03 May 2016 14:30:14 -0400 Received: from mga04.intel.com ([192.55.52.120]:25278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axf5E-0001SX-4K for qemu-devel@nongnu.org; Tue, 03 May 2016 14:30:08 -0400 References: <1461744786-47643-1-git-send-email-guangrong.xiao@linux.intel.com> <20160428173443.GA24153@thinpad.lan.raisama.net> <57284774.7010401@linux.intel.com> <20160503161131.GN4457@thinpad.lan.raisama.net> <5728E374.4020809@linux.intel.com> <5728E5A7.9020709@intel.com> <20160503182352.GO4457@thinpad.lan.raisama.net> From: Dave Hansen Message-ID: <5728EE11.3090601@intel.com> Date: Tue, 3 May 2016 11:29:37 -0700 MIME-Version: 1.0 In-Reply-To: <20160503182352.GO4457@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] XSAVES in GET_SUPPORTED_CPUID (was Re: [PATCH] target-i386: add Skylake-Client cpu mode) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Xiao Guangrong , pbonzini@redhat.com, imammedo@redhat.com, kvm@vger.kernel.org, mst@redhat.com, gleb@kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com, dan.j.williams@intel.com, rth@twiddle.net, "Yu, Yu-cheng" , "Wang, Yong Y" , "Kasten, Robert A" , "Lai, Paul C" , "Xiao, Guangrong" , "ruwang@redhat.com" , "Shankar, Ravi V" , "Yu, Fenghua" 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.