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

[Eduardo Habkost]

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