[Qemu-devel] Not introducing new host-side requirements on new machine-type versions (was Re: [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models)

[Eduardo Habkost <ehabkost@redhat.com>]

I think this will reboot the discussion in a good way.

I have talked to Paolo on the phone, and I think I had a big assumption
that was not true:

On Wed, Jun 24, 2015 at 04:37:33PM +0200, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2015 at 11:24:46AM -0300, Eduardo Habkost wrote:
[...]
> > There are two kinds of changes introduced in new
> > machines:
> > 
> > 1) Guest-side-only ABI changes: those are OK, libvirt normally ignore
> >    them, they can't make a VM not-runnable.
> > 2) Changes in the host-side dependencies: those need to be more carefully
> >    controlled by libvirt. That's where CPU features are special: all CPU
> >    features depend KVM-side features, and enabling them by default on
> >    new machines makes it impossible for libvirt to know/report in
> >    advance what's necessary to make a VM runnable and to implement their
> >    existing runnability APIs[1].
[...]
> > Unless we guarantee that QEMU would never introduce type-(2) changes in
> > new machines (which I don't think will ever happen because that means
> > never changing existing CPU models in QEMU), libvirt needs to control
> > CPU features individually (that's why they need -cpu custom).
> 
> Did we ever do it? I don't think so, so yes, we very likely never will.

That was my big assumption. We did it before with KVM features (they
require KVM-side support), where new features were enabled by default on
new machine-types, I assumed we would do that again with any CPU
feature. We did it before when we added x2apic by default on all CPU
models in KVM (requiring a kernel capable of emulating x2apic).

In another message, Paolo wrote:
> libvirt should trust that QEMU developers will not prevent a VM from
> running on a previously viable host, just because you change the machine
> type.

I assumed that was never going to be true.

As long as QEMU guarantees that, so we don't change existing CPU models
(in new machines) in a way that introduces new host-side dependencies,
we will be OK.

We may need something new to implement this guarantee for KVM features,
though. libvirt will need something that says "please don't enable any
KVM CPUID bits silently for me, let me ask for them explicitly". But
that won't be as drastic as requiring "-cpu custom".

That have some consequences in the way we add new CPU models and
implement CPU model changes. For example: until we know all the features
we want in a CPU model are already available and supported in the latest
kernel, we won't add a new CPU model. The choice of features in CPU
models should be "final" as soon as we add the CPU model, so CPU model
changes should never introduce new host-side requirements. If a CPU
model change requires some additional KVM code or newer host CPU, we
need to add a new CPU model name. We must agree on that and document it,
because I expect to see some complaints in the future when enforcing
this rule.

> 
> It's as if someone wrote a wrapper around all kernel system calls
> on the assumption that kernel can not guarantee kernel/userspace ABI
> will never change. It can and it does.
> 
> So let's promise not to break things, and avoid a ton of copy and paste bugs.

My assumption was that this (introducing type-(2) machine changes) was
never considered "breaking things" and just a fact of life.

If we guarantee that we will never prevent a VM from running on a
previously viable host, just because you change the machine type, we
will be OK.

-- 
Eduardo