Re: [PATCH] target/i386: add VMX features to named CPU models

[Eduardo Habkost]

On Wed, Nov 20, 2019 at 09:49:35PM +0100, Paolo Bonzini wrote:
> On 20/11/19 19:45, Eduardo Habkost wrote:
> > On Wed, Nov 20, 2019 at 06:37:53PM +0100, Paolo Bonzini wrote:
> >> This allows using "-cpu Haswell,+vmx", which we did not really want to
> >> support in QEMU but was produced by Libvirt when using the "host-model"
> >> CPU model.
> > 
> > I understand guest ABI compatibility is not a concern, but I
> > don't remember how we guarantee it won't break by accident if
> > somebody tries to live migrate a VM.
> 
> I'm not sure I understand the question, but I can answer the second part:
> 
> > What is supposed to happen today if trying to live migrate a VM
> > using "-cpu Haswell,+vmx"?
> 
> Before 4.2: same guest ABI compatibility as "-cpu host".

Oh, I forgot that FEAT_KVM_* is recent and is not in QEMU 4.1.
If host-independent guest ABI was never guaranteed before, we're
not making it worse.

For how long was this broken?  Jiri, was libvirt including +vmx
in mode=host-model for a long time, or is this something recent?


> 
> 4.2+: ABI compatibility is preserved, because each named CPU model can
> be given a precise set of features that are matched against the host
> (and are subject to check/enforce).

Good.

> 
> 4.1->4.2: the ABI *should* be preserved if you're running "-cpu
> SandyBridge,+vmx" on an actual Sandy Bridge, but some VMX features will
> disappear after live migration if e.g. you're running "-cpu
> SandyBridge,+vmx" on a Haswell.  Host-model should be fine though.

That was the case I was worried about.

So, host-model should be fine in theory, because the CPU model
chosen by libvirt is supposed to match the host CPU.  Good.

All the other cases already had an unpredictable host-dependent
guest ABI, and can't be fixed.  Bad, but I don't think we can do
anything about it.

So:

Reviewed-by: Eduardo Habkost <address@hidden>


It would be nice if we at least printed a warning when using +vmx
with pc-*-4.1 and older, so people know their configuration is
likely to be broken.

-- 
Eduardo