From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: XSAVES in GET_SUPPORTED_CPUID (was Re: [Qemu-devel] [PATCH] target-i386: add Skylake-Client cpu mode) Date: Thu, 12 May 2016 14:06:46 +0200 Message-ID: <573471D6.8050102@redhat.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> <5728E5A7.9020709@intel.com> <57309459.8080501@redhat.com> <20160512120331.GM4457@thinpad.lan.raisama.net> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Dave Hansen , Xiao Guangrong , 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: Eduardo Habkost Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39083 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752517AbcELMGz (ORCPT ); Thu, 12 May 2016 08:06:55 -0400 In-Reply-To: <20160512120331.GM4457@thinpad.lan.raisama.net> Sender: kvm-owner@vger.kernel.org List-ID: On 12/05/2016 14:03, Eduardo Habkost wrote: > > 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. > > Agreed. Now, should we name the CPU model without XSAVES > "Skylake" or "Skylake-noXSAVES"? I'm inclined towards the latter, > to follow the same pattern we used for "Haswell-noTSX". Do we have a plan to add Skylake with XSAVES? I think no, so it should be fine to do .name = "Skylake", .features[FEATURE_XSAVE] = CPUID_XSAVE_XSAVEOPT | CPUID_XSAVE_XGETBV1 | CPUID_XSAVE_XSAVEC /* omitting CPUID_XSAVE_XSAVES because... */ Haswell-noTSX was added only because we already had a model with TSX. If we hadn't we probably would have had: - Haswell without TSX - Broadwell without TSX - Broadwell-EX with TSX (or something like that). Thanks, Paolo