From: "Michael S. Tsirkin" <mst@redhat.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cc: vit9696 <vit9696@protonmail.com>,
Stefan Reiter <s.reiter@proxmox.com>,
qemu devel list <qemu-devel@nongnu.org>,
Igor Mammedov <imammedo@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>,
Laszlo Ersek <lersek@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [PATCH 1/2] i386/acpi: fix inconsistent QEMU/OVMF device paths
Date: Sun, 28 Feb 2021 15:45:24 -0500 [thread overview]
Message-ID: <20210228154404-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <e36b3025-d709-1a6c-6b5a-a08bc6de819f@proxmox.com>
On Sun, Feb 28, 2021 at 11:43:55AM +0100, Thomas Lamprecht wrote:
> Hi Vitaly,
>
> On 28.02.21 10:11, vit9696 wrote:
> > For us this breaks the ability to control the boot options between the operating system and the OVMF. It happens because the operating system builds the DPs based on ACPI (in fact the only source available to it), while OVMF uses another source. The previous behaviour also violates the specification, so I do not believe there is room for reverting it. I believe it is also not possible to update QEMU to internally use the 1 UID, since it may conflict with the case when there are multiple PCI bus.
>
> I think you may have misunderstood me a little bit, I did not ask for this to
> be reverted in upstream QEMU, it's quite clear to me that this should be the
> new default behaviour and should have been since ever.
We do make an effort to avoid guest visible changes within machine
version though. this is what we should do here I think.
--
MST
next prev parent reply other threads:[~2021-02-28 21:11 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 [this message]
[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
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=20210228154404-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=lersek@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=s.reiter@proxmox.com \
--cc=t.lamprecht@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).