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
