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