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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
