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

[Daniel P. Berrange]

On Tue, Jun 23, 2015 at 02:24:16PM -0300, Eduardo Habkost wrote:
> 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.

It also has a positive impact on maintenance. By allowing libvirt to
control the CPU definitions, in cases where there is a need to push
out a CPU model bugfix, libvirt will often be able to make the update
available to users via a new CPU model version, without them having
to do a lock-step upgrade to QEMU at the same time.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|