From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtYlt-0000cW-Hs for qemu-devel@nongnu.org; Wed, 26 Nov 2014 04:20:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XtYlk-0001Cv-GW for qemu-devel@nongnu.org; Wed, 26 Nov 2014 04:20:25 -0500 Received: from mail-wg0-x235.google.com ([2a00:1450:400c:c00::235]:49933) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XtYlk-0001Co-9h for qemu-devel@nongnu.org; Wed, 26 Nov 2014 04:20:16 -0500 Received: by mail-wg0-f53.google.com with SMTP id l18so3062698wgh.26 for ; Wed, 26 Nov 2014 01:20:15 -0800 (PST) Sender: Paolo Bonzini Message-ID: <54759B4C.5060601@redhat.com> Date: Wed, 26 Nov 2014 10:20:12 +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> In-Reply-To: <5474E05E.7090509@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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 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). 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? Paolo