Il 28/04/2014 17:46, Eduardo Habkost ha scritto:
So I couldn't indeed think of uses of "-cpu host" together with
migration. But if you're sure there is none, block it in QEMU.
There's no reason why this should be specific to libvirt.
It's not that there are no useful use cases, it is that we simply can't
guarantee it will work because (by design) "-cpu host" enables features
QEMU doesn't know about (so it doesn't know if migration is safe or
not). And that's the main use case for "-cpu host".
True, but in practice QEMU and KVM support is added in parallel, and we
already have full support for Broadwell (IIRC) and are starting to add
Skylake features.
So, what about doing the following on QEMU 2.1:
* "-cpu host,migratable=yes":
* No invtsc
* Migration not blocked
* No feature flag unknown to QEMU will be enabled
* "-cpu host,migratable=no":
* invtsc enabled
* Unknown-to-QEMU features enabled
* Migration blocked
* "-cpu host":
* Same behavior as "-cpu host,migratable=yes"
* Release notes indicating that "-cpu host,migratable=no" is
required if the user doesn't care about migration and wants new
(unknown to QEMU) features to be available
I was going to propose making "migratable=no" the default after a few
releases, as I expect the majority of existing users of "-cpu host" to
not care about migration. But I am not sure, because there's less harm
in _not_ getting new bleeding edge features enabled, and those users
(and management software) can start using "migratable=no" if they really
want the new unmigratable features.
Makes sense. Basically "-cpu host,migratable=yes" is close to libvirt's
host-model and Alex Graf's proposed "-cpu best". Should we call it
"-cpu best" and drop migratability of "-cpu host"?
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
