From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59946) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azlUj-0000fh-Dd for qemu-devel@nongnu.org; Mon, 09 May 2016 09:45:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1azlUf-0007pP-LV for qemu-devel@nongnu.org; Mon, 09 May 2016 09:45:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1azlUf-0007pD-Fn for qemu-devel@nongnu.org; Mon, 09 May 2016 09:45:05 -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> From: Paolo Bonzini Message-ID: <57309459.8080501@redhat.com> Date: Mon, 9 May 2016 15:44:57 +0200 MIME-Version: 1.0 In-Reply-To: <5728E5A7.9020709@intel.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Dave Hansen , Xiao Guangrong , Eduardo Habkost Cc: 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 03/05/2016 19:53, Dave Hansen wrote: > The guest's use of XSAVES is completely independent of what instruction= s > the host (kernel) uses for its xsave buffer. >=20 > 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...). True. In addition, there are other considerations to make: 1) right now, KVM is *not* planning to use XSAVES to marshal/unmarshal MSRs out of the hypervisor and back in. Instead it will use KVM_GET_MSR/KVM_SET_MSR. This is for at least two reasons. First, because KVM_GET_XSAVE/KVM_SET_XSAVE is still using the non-compacted XSAVE/XSAVEOPT format and there's simply no room (as far as I understasnd) for supervisor state save components in the non-compacted format. Second, because QEMU anway doesn't like treating the XSAVE area as a black box so we'd be parsing the fields around KVM_GET_XSAVE/KVM_SET_XSAVE. 2) KVM doesn't yet expose any XSAVES state save component, and the only one defined in Skylake (processor tracing) probably will block migration and will have to be added separately. Item number 1 means that it is particularly easy to re-enable XSAVES for guests only (and Dave's proposal later in the threaad sounds great). Item number 2 on the other hand means that it's okay to add Skylake CPU models without XSAVES. Because of the large number of kernels in the wild that block XSAVES, I'm inclined to do that. Thanks, Paolo