On Fri, Jan 20, 2017 at 03:30:54PM +0100, David Hildenbrand wrote: > Am 19.01.2017 um 18:45 schrieb Daniel P. Berrange: > > On Thu, Jan 19, 2017 at 06:21:22PM +0100, David Hildenbrand wrote: > >> > >>>> Also think about "query-cpu-model-expansion model=host type=static", > >>>> which will primarily be used by libvirt on s390x. There is no way to > >>>> expand this into a static cpu model. Faking anything will just hide errors. > >>> > >>> Yes, static expansion of host model must always return an error > >>> if it's not possible to expand. > >>> > >>>> > >>>> If "host" can't be expanded, QEMU has to be treated like there is no CPU > >>>> model support (as for older QEMU versions). > >>> > >>> OK. I will propose a patch updating the query-cpu-model-expansion > >>> documentation to be more explicit about it. > >> > >> The only real alternative I see would be disabling the query-cpu-model-* > >> interface completely if KVM support is not available. > >> > >> This would however mean, that the same QEMU binary would have the > >> interface when running under TCG, but not when running under KVM on an > >> old KVM version. > >> > >> That also doesn't really feel right, or what do you think? > > > > Yeah that really isn't good. query-cpu-model-* needs to work on TCG > > and *not* have a dependancy on KVM in that case, since you can be > > running TCG s390 on a x86_64 host, so the host CPU is totally irrelevant > > for TCG > > > > Actually what I meant was: > > TCG: query-cpu-model-* interface always provided > KVM (with cpu model support): query-cpu-model-* interface provided > KVM (without cpu model support): no query-cpu-model-* interface provided > > This would avoid having to report an error when expanding "host" in the > third case (KVM without cpu model support) but would lead to one QEMU > binary having a different set of supported qmp calls when called from > TCG and KVM. I don't think we should do that. Expansion of static and migration-safe CPU models is host-independent by design, so it should always work on any host. Management software could even choose to run CPU expansion on one host, and start the VM (using the results of the expansion) on a different host. -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
