qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eduardo Habkost
Subject: Re: [Qemu-devel] [PATCH 0/2] target-i386: "custom" CPU model + script to dump existing CPU models
Date: Wed, 24 Jun 2015 11:24:46 -0300
User-agent: Mutt/1.5.23 (2014-03-12)

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

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

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

-- 
Eduardo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]