On Tue, Jun 23, 2015 at 07:58:44PM +0200, Andreas Färber wrote: > Am 23.06.2015 um 19:45 schrieb Eduardo Habkost: > > On Tue, Jun 23, 2015 at 07:41:50PM +0200, Andreas Färber wrote: > > [...] > >> If that is the whole problem here, then why not just add a global flag > >> to only enable explicitly requested KVM features? All other features > >> should not depend on the host, and the whole discussion about -x.y seems > >> like a distraction. > > > > Now replace "KVM features" with "CPU fatures", because all CPU features > > are KVM features, as all of them depend on KVM code enabling them on > > GET_SUPPORTED_CPUID. > > > > Thus, the global flag to only enable explicitly request KVM features on > > CPUs is "-cpu custom", which doesn't enable any CPU feature at all. > > If libvirt wants to use an empty CPU model, then why export our models > to libvirt?
We wouldn't need it anymore. We would probably keep it just because old libvirt versions (or maybe the non-x86 libvirt code) may use it, or maybe libvirt will keep using the existing QEMU models for existing VMs (because that would be simpler than converting existing "-cpu Foo" to "-cpu custom -readconfig"). > > I don't mind there being an optional custom model, I mind our > compat_props getting ignored that way, which are unrelated to adding new > features, in fact they suppress just that for the -2.3 examples. I am also not happy for having spent lots of time on compat_props for CPUs when it is not going to be needed by libvirt anymore, but that's a sunk cost. -- Eduardo
