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

[Eduardo Habkost]

On Mon, Apr 28, 2014 at 09:06:42PM +0200, Paolo Bonzini wrote:
> 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"?

"-cpu best" is different from the modes above. It means "use the best
existing CPU model (from the pre-defined table) that can run on this
host".

And it would have the same ambiguities we found on "-cpu host": if a CPU
model in the table have invtsc enabled, should it be considered a
candidate for "-cpu best", or not?

-- 
Eduardo