qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
	Stefan Reiter <s.reiter@proxmox.com>,
	qemu-devel@nongnu.org, Igor Mammedov <imammedo@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <rth@twiddle.net>,
	Laszlo Ersek <lersek@redhat.com>,
	vit9696 <vit9696@protonmail.com>
Subject: Re: [PATCH 1/2] i386/acpi: fix inconsistent QEMU/OVMF device paths
Date: Mon, 1 Mar 2021 08:12:35 +0100	[thread overview]
Message-ID: <967d3e1f-d387-0b33-95b0-6560f49657dd@proxmox.com> (raw)
In-Reply-To: <20210228154208-mutt-send-email-mst@kernel.org>

On 28.02.21 21:43, Michael S. Tsirkin wrote:
> Sure. The way to do that is to tie old behaviour to old machine
> versions. We'll need it in stable too ...

Yeah, using machine types is how its meant to be with solving migration
breakage, sure.
But that means we have to permanently pin the VM, and any backup restored from
that to that machine type *forever*. That'd be new for us as we always could
allow a newer machine type for a fresh start (i.e., non migration or the like)
here, and mean that lots of other improvements guarded by a newer machine type
for those VMs will.

Why not a switch + machine type, solves migration and any special cases of it
but also allows machine updates but also to keep the old behavior?

And yeah, stable is wanted, but extrapolating from the current stable releases
frequency, where normally there's maximal one after 5-6 months from the .0
release, means that this will probably still hit all those distributions I
mentioned or is there something more soon planned?

Also, is there any regression testing infrastructure around to avoid such
changes in the future? This change got undetected for 7 months, which can be
pretty the norm for QEMU releases, so some earlier safety net would be good? Is
there anything which dumps various default machine HW layouts and uses them for
an ABI check of some sorts?



  reply	other threads:[~2021-03-01  7:13 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30 15:58 [PATCH 1/2] i386/acpi: fix inconsistent QEMU/OVMF device paths Michael S. Tsirkin
2020-07-30 15:58 ` [PATCH 2/2] arm/acpi: fix an out of spec _UID for PCI root Michael S. Tsirkin
2020-07-30 16:12   ` Philippe Mathieu-Daudé
2020-07-30 19:35   ` Laszlo Ersek
2020-07-30 20:33   ` Peter Maydell
2020-07-31  9:31   ` Igor Mammedov
2020-07-30 16:11 ` [PATCH 1/2] i386/acpi: fix inconsistent QEMU/OVMF device paths Philippe Mathieu-Daudé
2020-07-30 19:35   ` Michael S. Tsirkin
2020-07-31  2:55     ` vit9696 via
2020-07-30 19:34 ` Laszlo Ersek
2020-07-31  9:30 ` Igor Mammedov
2021-02-27 19:41 ` Thomas Lamprecht
2021-02-28  9:11   ` vit9696
2021-02-28 10:43     ` Thomas Lamprecht
2021-02-28 20:45       ` Michael S. Tsirkin
     [not found]       ` <x3i3TiibtrC1qTDQUKxuOA_9qvmInzVwv6RrvzzSCSj-S21gLypbbZgEbYvJSGMxC1r8RaDrnHGgRbDI7vfpA_XuDINdZej9yKCW3_Sc4YM=@protonmail.com>
2021-02-28 21:37         ` Michael S. Tsirkin
2021-02-28 20:43   ` Michael S. Tsirkin
2021-03-01  7:12     ` Thomas Lamprecht [this message]
2021-03-01  7:20       ` Michael S. Tsirkin
2021-03-01  7:45         ` Thomas Lamprecht
2021-03-01 14:20           ` Igor Mammedov
2021-03-01 14:27             ` Thomas Lamprecht
2021-03-01 20:16               ` Igor Mammedov
2021-03-01 15:31           ` Michael S. Tsirkin
2021-03-01 13:28     ` Igor Mammedov
2021-03-01 16:14       ` Michael S. Tsirkin
2021-03-01 16:28         ` Laszlo Ersek
2021-03-01 19:08           ` Igor Mammedov
2021-03-01 20:06             ` vit9696
2021-03-02  8:40             ` Laszlo Ersek
2023-04-18  9:06 zhangying (AZ) via
2023-04-19  2:48 zhangying (AZ) via
2023-04-20 14:54 ` Igor Mammedov

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=967d3e1f-d387-0b33-95b0-6560f49657dd@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=ehabkost@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=lersek@redhat.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=s.reiter@proxmox.com \
    --cc=vit9696@protonmail.com \
    /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).