qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: qemu-stable@nongnu.org, Laurent Vivier <laurent@vivier.eu>,
	qemu-devel@nongnu.org
Subject: Re: [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1
Date: Tue, 9 Nov 2021 12:55:25 +0000	[thread overview]
Message-ID: <YYpvvWLvkhR0/igt@redhat.com> (raw)
In-Reply-To: <9537b527-d33e-59d5-e196-e1e84fa01325@eik.bme.hu>

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)
> >     } \
> >     type_init(machvirt_machine_##major##_##minor##_init);
> > 
> > +static void virt_machine_6_1_options(MachineClass *mc)
> > +{
> > +}
> > +DEFINE_VIRT_MACHINE(6, 1, true)
> > +
> > 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);
> > }
> > -DEFINE_VIRT_MACHINE(6, 0, true)
> > +DEFINE_VIRT_MACHINE(6, 0, false)
> 
> 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
arch


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



  reply	other threads:[~2021-11-09 12:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-09 11:15 [PULL 0/2] M68k for 6.2 patches Laurent Vivier
2021-11-09 11:15 ` [PULL 1/2] hw: m68k: virt: Add compat machine for 6.1 Laurent Vivier
2021-11-09 12:34   ` BALATON Zoltan
2021-11-09 12:55     ` Daniel P. Berrangé [this message]
2021-11-09 19:58       ` BALATON Zoltan
2021-11-09 21:27         ` Peter Maydell
2021-11-09 23:33           ` BALATON Zoltan
2021-11-10 14:27             ` Peter Maydell
2021-11-10 14:35         ` Daniel P. Berrangé
2021-11-09 11:15 ` [PULL 2/2] hw: m68k: virt: Add compat machine for 6.2 Laurent Vivier
2021-11-09 15:07 ` [PULL 0/2] M68k for 6.2 patches Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YYpvvWLvkhR0/igt@redhat.com \
    --to=berrange@redhat.com \
    --cc=balaton@eik.bme.hu \
    --cc=laurent@vivier.eu \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).