Re: [PATCH] target-i386: fix losing XCR0 processor state component bits

[Eduardo Habkost <ehabkost@redhat.com>]

On Wed, Sep 28, 2016 at 06:07:13PM +0200, Paolo Bonzini wrote:
> 
> 
> On 28/09/2016 17:59, Eduardo Habkost wrote:
> > 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".
> 
> So instead of looking at wi->feat_names[i] we could have a wrapper that
> returns the name and special cases xsave components words?  This should
> be used in both x86_cpu_get_migratable_flags and
> report_unavailable_features, but not elsewhere as far as I could see.

Sounds good to me. I will do it.

-- 
Eduardo