From mboxrd@z Thu Jan  1 00:00:00 1970
From: Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [PATCH] target-i386: fix losing XCR0 processor state component
 bits
Date: Wed, 28 Sep 2016 12:59:35 -0300
Message-ID: <20160928155935.GL3877@thinpad.lan.raisama.net>
References: <1475040669-29085-1-git-send-email-wanpeng.li@hotmail.com>
 <b8f568ac-64a3-852c-deb5-fa67fc147005@gnu.org>
 <20160928145737.GJ3877@thinpad.lan.raisama.net>
 <67000e1f-e521-e293-6d61-80f1c41976dc@gnu.org>
 <20160928150553.GK3877@thinpad.lan.raisama.net>
 <625b529e-5306-34f1-2429-c6d335280882@gnu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Wanpeng Li <kernellwp@gmail.com>, kvm@vger.kernel.org,
        qemu-devel@nongnu.org, Wanpeng Li <wanpeng.li@hotmail.com>,
        Richard Henderson <rth@twiddle.net>,
        "Michael S. Tsirkin" <mst@redhat.com>
To: Paolo Bonzini <bonzini@gnu.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:53648 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S932950AbcI1P7i (ORCPT <rfc822;kvm@vger.kernel.org>);
        Wed, 28 Sep 2016 11:59:38 -0400
Content-Disposition: inline
In-Reply-To: <625b529e-5306-34f1-2429-c6d335280882@gnu.org>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Wed, Sep 28, 2016 at 05:09:46PM +0200, Paolo Bonzini wrote:
> 
> 
> On 28/09/2016 17:05, Eduardo Habkost wrote:
> > > Hmm, right.  Even though XSAVE could be migrated as a blob, QEMU
> > > marshals and unmarshals the registers out and back into the xsave data,
> > > so that unknown features are indeed unmigratable.
> > > 
> > > But are the property names necessary?  It makes no sense to
> > > enable/disable XSAVE components separately from the other CPUID bits
> > > that enable them.  Could we just mark all unknown features as
> > > unmigratable without giving them names?
> >
> > We could, as we don't really need to make them configurable. But
> > giving them names will also allow us to return more useful data
> > to libvirt in case GET_SUPPORTED_CPUID returns some bits as
> > unsupported. The new CPU runnability/comparison APIs are all
> > based on property names.
> 
> The names could, or perhaps should, be obtained also from
> x86_ext_save_areas (apart from the legacy x87 and sse components which
> are guaranteed to be there).  Basically property names such as "avx"
> trigger both the regular CPUID bits and the XSAVE components.

Yes, this makes sense. If XSTATE_YMM_BIT is missing, for example,
it is more useful to say "avx" is unsupported by the host, than
something like "xsave-component-ymm".

-- 
Eduardo