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. Paolo -- 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
