Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models

[Michael S. Tsirkin]

On Wed, Jun 24, 2015 at 11:24:46AM -0300, Eduardo Habkost wrote:
> On Tue, Jun 23, 2015 at 11:34:45PM +0200, Michael S. Tsirkin wrote:
> > On Tue, Jun 23, 2015 at 02:11:22PM -0300, Eduardo Habkost wrote:
> > > Even if it is a bug fix. If it is a change that can make the VM
> > > unrunnable, it needs to be controlled by a separate flag, not by the
> > > machine-type.
> > 
> > I agree - command line compatibility is important.  But we are supposed
> > to provide that.  I am surprised that libvirt suddenly wants to avoid
> > some command line flags because they are not stable. IMHO we did something
> > wrong here if so. Maybe there was a valid reason for it. But then won't
> > it apply to libvirt as well?
> 
> Maybe we are having the same misunderstanding here: the problem is not
> compatibility/stability of existing machines, but the kind of
> (intentional) changes introduced in _new_ machines (when the -machine
> argument is changed). 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].

Not all that special.  e.g. virtio device offloads depend on host
networking's ability to offload them too. And hey, QEMU is part of host
too, so if you want to be pedantic, any device configuration might be
broken on an old host and fixed on a new one, so vm seems to run but
will lose data or crashes.

All this is unusual enough that no one bothers.

> 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.

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.


> > 
> > Now, if people want to update CPU models outside the QEMU binary,
> > that might be doable simply by moving them to a separate package,
> > with a text file that QEMU reads at startup.
> 
> You seem to be describing exactly what is made possible by
> "-cpu custom -readconfig <cpu-config-file>"
> 
> 
> [1] http://libvirt.org/html/libvirt-libvirt-host.html#virConnectCompareCPU
>     (See the cover letter of this series)

Only if you also add the config files as part of qemu, reworking
existing models to load config file from a pre-defined directory.

My whole point is to avoid useless code duplication.

> -- 
> Eduardo