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

["Andreas Färber" <afaerber@suse.de>]

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.

>> Would a qemu64-2.3 model help here that pc*-2.3 could use? I believe
>> that's been proposed in the past. I don't oppose the idea of a
>> fully-custom CPU, but this blatant attempt of ignoring QEMU's CPU
>> versioning by libvirt worries me.
> 
> That is still tieing CPU model names to machine type versions, unless
> I'm mis-understanding you. In general having QEMU models avialable
> vary depending on the QEMU version is creating problems for apps
> higher up the stack. By allowing libvirt to define the CPU model
> policy, it can also provide a more consistent interface to applications
> above, such as OpenStack, which will facilitate work in the schedular
> when it picks hosts capable of deploying/migrating a VM, when there
> are heterogenous QEMU versions across the hosts.

If you have heterogeneous QEMUs across hosts, then you need a
common-denominator machine anyway because QEMU wouldn't start with a
machine it doesn't know.

Please give one concrete example of a real-world problem instead of
hypothetical abstract combinations users may or may not be able to
construct.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB
21284 (AG Nürnberg)