On Tue, Jun 23, 2015 at 07:10:11PM +0200, Andreas Färber wrote: > Am 23.06.2015 um 18:53 schrieb Daniel P. Berrange: > > On Tue, Jun 23, 2015 at 06:40:19PM +0200, Andreas Färber wrote: > >> Am 23.06.2015 um 18:25 schrieb Daniel P. Berrange: > >>> Whether QEMU changed the CPU for existing machines, or only for new > >>> machines is actually not the core problem. Even if we only changed > >>> the CPU in new machines that would still be an unsatisfactory situation > >>> because we want to be able to be able to access different versions of > >>> the CPU without the machine type changing, and access different versions > >>> of the machine type, without the CPU changing. IOW it is the fact that the > >>> changes in CPU are tied to changes in machine type that is the core > >>> problem. > >> > >> This coupling is by design and we expect all KVM/QEMU users to adhere to > >> it, including those that use the libvirt tool (which I assume is going > >> to be the majority of KVM users). Either you want a certain > >> backwards-compatible machine and CPU, or you want the latest and > >> greatest - why in the world mix and match?! > > > > As mentioned, changes/fixes to the CPU model can affect the ability to > > launch the guest on a particular host, so we need the ability to control > > when those CPU changes are activated for a guest, separately from the > > machine type. > > Why? Today's libvirt with QEMU 2.3 resolves "pc" machine to > "pc-i440fx-2.3" and the guest XML stays that way. When we add new > features for 2.4, 2.3 is guaranteed to stay compatible. Any change would > involve the libvirt user actively switching from pc-i440fx-2.3 to a > different machine such as upcoming pc-i440fx-2.4. Why do you need to > change the CPU separately? Why would a user want to run 2.2's CPU with a > 2.3 machine? Or a 2.3 machine with a 2.4 CPU? That's nonsense. If you > want to tweak features, you already have command line options available > to do so on the basis of what the selected machine provides.
Because pure guest-side ABI changes are different from changes that also have additional host-side requirements, so we want to untie both things. About being able to tweak features today, that's true: we have command-line options for most stuff and that's _almost_ enough for what libvirt needs. What's missing is something to avoid silently getting new features that libvirt aren't aware of (but may make the VM unrunnable). The purpose of "-cpu custom" is to ensure no new host side feature requirement will be introduced silently, even if choosing a different machine. -- Eduardo