Re: [patch 2/2] target-i386: block migration and savevm if invariant tsc is exposed

[Paolo Bonzini <pbonzini@redhat.com>]

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