All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: QEMU Development <qemu-devel@nongnu.org>,
	Peter Xu <peterx@redhat.com>, Fabiano Rosas <farosas@suse.de>,
	Christian Ehrhardt <christian.ehrhardt@canonical.com>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: migration: stable machine types?
Date: Mon, 23 Feb 2026 10:46:49 +0000	[thread overview]
Message-ID: <aZwwGW7ERvH555zg@redhat.com> (raw)
In-Reply-To: <eabe1076-d30c-4454-8558-a231b9cb228d@tls.msk.ru>

On Sat, Feb 21, 2026 at 09:55:55AM +0300, Michael Tokarev wrote:
> Hi!
> 
> We had a few examples when a bugfix required for a stable series
> but it can't be applied because it breaks migration.  One recent
> example is https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2131822 -
> the fix has been cherry-picked for 10.0.x but had to be reverted.
> 
> I wonder if we can, sometimes, introduce additional machine types
> for stable series.
> 
> In this case, it might've been an intermediate 10.0.4 machine type,
> which is between 10.0 and 10.1 - with this additional change included.
> 
> If this machine is known to both 10.1-tobe and 10.0.4+, all migration
> should work fine in both directions.

Yep, any bug fix machine would need to be added to 'master' branch
too, and any intermediate stable branches - though the latter probably
wouldn't ever happen as machine version mistakes are usually discovered
reasonably soon.

> It is exactly the same situation and solution which has been implemented
> by ubuntu in the end, but using their own, distribution-specific,
> machine types.
> 
> Why can't we do the same in upstream qemu?

There is no constraint from a technical POV. The macros I introduced
for defining versioned machine types in a standardized manner, can
have variants provided that define "bug fix" machines for stable
branches. We have a pretty old example for Q35:

  hw/i386/pc_q35.c:DEFINE_Q35_MACHINE_BUGFIX(4, 0, 1);

We used to have another example for PPC, which used the _MACHINE_TAGGED
variant, which added a string suffix instead of a micro version number,
but I'd recommend we don't use string suffixes again, only micro versions.

The core reason we didn't do this in the past was the support workload,
as every extra machine type we add is one more thing to maintain...
previously this burden was forever, but at least now we have capped
versioned machines at 6 years / 18 minor releases total lifetime.
Thus if we did add bugfix machines, that burden is now capped and
thus more tolerable.


IOW, if you as stable maintainer want to add a bugfix machine, and
the subsystem maintainer for that machine is aggreeable to adding
it too, there is no fundamental blocker here.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|



  reply	other threads:[~2026-02-23 10:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-21  6:55 migration: stable machine types? Michael Tokarev
2026-02-23 10:46 ` Daniel P. Berrangé [this message]
2026-02-23 19:37   ` Peter Xu
2026-02-23 20:06     ` Daniel P. Berrangé

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=aZwwGW7ERvH555zg@redhat.com \
    --to=berrange@redhat.com \
    --cc=christian.ehrhardt@canonical.com \
    --cc=farosas@suse.de \
    --cc=mjt@tls.msk.ru \
    --cc=peter.maydell@linaro.org \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.