From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xtbzo-0002tw-Ov for qemu-devel@nongnu.org; Wed, 26 Nov 2014 07:47:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xtbzi-0006Kh-Ji for qemu-devel@nongnu.org; Wed, 26 Nov 2014 07:47:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xtbzi-0006Kd-Al for qemu-devel@nongnu.org; Wed, 26 Nov 2014 07:46:54 -0500 Message-ID: <5475CBB9.9070104@redhat.com> Date: Wed, 26 Nov 2014 13:46:49 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1416936942-32516-1-git-send-email-pbonzini@redhat.com> <20141125184517.GP3137@thinpad.lan.raisama.net> <5474E05E.7090509@redhat.com> <54759B4C.5060601@redhat.com> <20141126114036.GQ3137@thinpad.lan.raisama.net> In-Reply-To: <20141126114036.GQ3137@thinpad.lan.raisama.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] target-i386: add feature flags for CPUID[EAX=0xd, ECX=1] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 26/11/2014 12:40, Eduardo Habkost wrote: > On Wed, Nov 26, 2014 at 10:20:12AM +0100, Paolo Bonzini wrote: >> >> >> On 25/11/2014 21:02, Paolo Bonzini wrote: >>>>> +static const char *cpuid_xsave_feature_name[] = { >>>>> + "xsaveopt", "xsavec", "xgetbv1", "xsaves", >>>> >>>> None of the above features introduce any new state that might need to be >>>> migrated, or will require other changes in QEMU to work, right? >>>> >>>> It looks like they don't introduce any extra state, but if they do, they >>>> need to be added to unmigratable_flags until migration support is >>>> implemented. >>>> >>>> If they require other QEMU changes, it would be nice if KVM reported >>>> them using KVM_CHECK_EXTENSION instead of GET_SUPPORTED_CPUID, so it >>>> wouldn't break "-cpu host". >>> >>> No, they don't. >> >> Actually, xsaves does but I don't think KVM_CHECK_EXTENSION is right. >> It's just another MSR, and we haven't used KVM_CHECK_EXTENSION for new >> MSRs and new XSAVE areas (last example: avx512). > > If the changes needed are only to support migration (this is the case if > it's just another MSR handled by KVM, or additional XSAVE areas), > GET_SUPPORTED_CPUID is still reasonable, because features that are > unknown to QEMU are always considered unmigratable until we add the > feature name to the feature_name arrays. (That's why we need to know if > the feature introduces additional state when adding the feature names to > the array.) > > If other changes are required to make the feature work even if no > migration is required, then adding them to GET_SUPPORTED_CPUID would > break "-cpu host" on older QEMUs. I don't think that's the case here, > but I wanted to confirm. KVM may need more changes (I don't know, the details of the feature are not public yet), but a new userspace API is very unlikely based on Intel documentation. > (Should we add those observations to Documentation/virtual/kvm/api.txt?) > >> >> Since no hardware really exists for it, and KVM does not support it >> anyway, I think it's simplest to leave xsaves out for now. Is this right? > > If unsure, it won't hurt to add the feature to unmigratable_features by > now. Making QEMU aware of the feature name is still useful. Ok, thanks. Paolo