From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: Re: XSAVES in GET_SUPPORTED_CPUID (was Re: [Qemu-devel] [PATCH] target-i386: add Skylake-Client cpu mode) Date: Tue, 3 May 2016 10:53:43 -0700 Message-ID: <5728E5A7.9020709@intel.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: 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" , "virt-intel-list@redhat.com" , "Kasten, Robert A" , "Lai, Paul C" , "Xiao, Guangrong" , "ruwang@redhat.com" , "Shankar, Ravi V" , "Yu, Fenghua" To: Xiao Guangrong , Eduardo Habkost Return-path: Received: from mga11.intel.com ([192.55.52.93]:34255 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934291AbcECRxt (ORCPT ); Tue, 3 May 2016 13:53:49 -0400 In-Reply-To: <5728E374.4020809@linux.intel.com> Sender: kvm-owner@vger.kernel.org List-ID: 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...). From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34488) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axeWe-0005NQ-ME for qemu-devel@nongnu.org; Tue, 03 May 2016 13:54:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axeWT-0004Ex-1y for qemu-devel@nongnu.org; Tue, 03 May 2016 13:54:19 -0400 Received: from mga04.intel.com ([192.55.52.120]:20494) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axeWS-0003vE-ST for qemu-devel@nongnu.org; Tue, 03 May 2016 13:54:12 -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> From: Dave Hansen Message-ID: <5728E5A7.9020709@intel.com> Date: Tue, 3 May 2016 10:53:43 -0700 MIME-Version: 1.0 In-Reply-To: <5728E374.4020809@linux.intel.com> Content-Type: text/plain; charset=utf-8 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: Xiao Guangrong , Eduardo Habkost Cc: 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" , "virt-intel-list@redhat.com" , "Kasten, Robert A" , "Lai, Paul C" , "Xiao, Guangrong" , "ruwang@redhat.com" , "Shankar, Ravi V" , "Yu, Fenghua" 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...).