[Top][All Lists]

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

Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1

From: BALATON Zoltan
Subject: Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1
Date: Tue, 9 Nov 2021 20:58:58 +0100 (CET)

On Tue, 9 Nov 2021, Daniel P. Berrangé wrote:
On Tue, Nov 09, 2021 at 01:34:49PM +0100, BALATON Zoltan wrote:
On Tue, 9 Nov 2021, Laurent Vivier wrote:
Add the missing machine type for m68k/virt

Cc: qemu-stable@nongnu.org
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Message-Id: <20211106194158.4068596-2-laurent@vivier.eu>
Signed-off-by: Laurent Vivier <laurent@vivier.eu>
hw/m68k/virt.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
index 4e8bce5aa6f7..0d9e3f83c169 100644
--- a/hw/m68k/virt.c
+++ b/hw/m68k/virt.c
@@ -304,7 +304,14 @@ type_init(virt_machine_register_types)
    } \

+static void virt_machine_6_1_options(MachineClass *mc)
static void virt_machine_6_0_options(MachineClass *mc)
+    virt_machine_6_1_options(mc);
+    compat_props_add(mc->compat_props, hw_compat_6_0, hw_compat_6_0_len);

I don't understand how these compat machines work but if these are empty and
essentially the same as the previous version why do we add a new version in
every release? Wouldn't it be enough to add new version when there was an
incompatible change? I mean, instead of listing machine and getting a lot of
virt-6.1, virt-6.0, virt-5.2,... or so, we'd only get versions that are
actually different such as virt-7.0, virt-5.2, virt-5.0 (maybe they are
called differently, just an example) with the versionless alias always
pointing to the latest. Then when QEMU is updated one can see if there was
any change so should update the VM or keep using the older versions. Or does
it work like that and I'm missing it completely?

It doesn't work like that, and that's a good thing.

The versioned machine types are for management applications that want
to guarantee an ABI across hosts. When a mgmt app wants to set a new
baseline for their QEMU machine types, it is way clearer if every
versioned machine type across all target arches supports the same
versions, regardless of whether there were any changes or not.

ie if an app wants to set QEMU 6.1.0 as the baseline, they want
to be able to set  virt-6.1 for aarch64, for mips, for riscv,
instead of having to figure out which versions exists for each

With a bit more logic the management app could easily implement this either by dereferencing the alias when creating the VM, say virt is an alias of virt-6,0 in QEMU 6.2 then put virt-6.0 in the VM config which then will work on anyting newer than QEMU 6.0. Or record the QEMU version in VM config when creating the VM saying this needs at least QEMU 6.1 then if there's no virt-6.1 or virt points to something newer then go back to the biggest version less than 6.1 (this might be more difficult due to changes in QEMU versioning but if we assume that at least they are increasing numbers it should be possible to find the largest version less than 6.1 for example). That way when a user types -machine help they won't get a large list of useless versioned machines that are mostly the same anyway. This looks like a case that a lazy management sofrware pollutes the human interface while it could handle it itself. But that's just my opinion, I don't use these too much so don't care too much either. It just looked like something that is putting a burden both on users and debelopers (having to add more compatiblity stuff to code that's already heavy on boilerplate) for something that could be handled within the management software. But maybe it's too late to change at this point.


reply via email to

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