qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] machines and versions - why so many?


From: Paolo Bonzini
Subject: Re: [Qemu-devel] machines and versions - why so many?
Date: Mon, 23 Jun 2014 16:59:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

Il 23/06/2014 16:15, Alexey Kardashevskiy ha scritto:
Hi!

I have been hearing recently that we (server PPC) should have more that
just one pseries machine in QEMU because this is what everybody else does :)

If you want to support live upgrades from QEMU 2.1 to QEMU 2.2, you should indeed prepare by adding a stable name such as pseries-2.1 already in QEMU 2.1.

My current understanding is that multiple machines (like
pc-i440fx-1.4..2.1, and many others) are needed:

3) for devices which are created explicitly and for which we want some
capabilities be disabled and we do not want to bother about this every time
we run QEMU;

This is not the exact reason. What you wrote _could_ be a reason to use compat_properties, but it is not why x86 has multiple machine types.

The reason is because when you migrate from QEMU 1.7 to QEMU 2.1, the machine should behave exactly the same as it did in QEMU 1.7. Any guest-visible change introduced between QEMU 1.7 and QEMU 2.1 (*) must be removed from QEMU 2.1. This is the reason why x86 has one machine type per version.

    (*) X got faster is not a guest-visible change.  A guest-visible
        change is something like:

        - a register gets a new default value

        - a register that was read-only is now read-write

        - the size of a memory region changed (e.g. a ROM BAR grew
          from 128k to 256k)

        Sometimes, if no known guest is using the register (e.g. only
        firmware uses it) it is okay to skip the creation of the
        compat property.  However, if in doubt, better add it.

ok, this one makes some sense for "pseries" to have (and upcoming
endianness register on VGA seems to be the case) but it seems that adding a
"compat" or "feature" property to the VGA device (and other devices which
deal with this kind of compatibility) is still more architecturally correct
thing to do, and let libvirt deal with the rest.

Yes, this sounds sensible.

Paolo

Since I (almost) always miss the bigger picture, what do I miss now? :) Thanks!






reply via email to

[Prev in Thread] Current Thread [Next in Thread]