From: "Michael S. Tsirkin" <mst@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: ghammer@redhat.com, Paolo Bonzini <pbonzini@redhat.com>,
imammedo@redhat.com, qemu-devel@nongnu.org,
shannon.zhao@linaro.org
Subject: Re: [Qemu-devel] [PATCH v2 0/4] acpi: xsdt support
Date: Thu, 27 Aug 2015 20:58:31 +0300 [thread overview]
Message-ID: <20150827205706-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <55DF1E34.4030503@redhat.com>
On Thu, Aug 27, 2015 at 04:27:00PM +0200, Laszlo Ersek wrote:
> On 06/09/15 16:05, Michael S. Tsirkin wrote:
> > On Tue, Jun 09, 2015 at 04:02:08PM +0200, Laszlo Ersek wrote:
> >> On 06/09/15 11:49, Michael S. Tsirkin wrote:
> >>> On Tue, Jun 09, 2015 at 02:02:31AM -0400, Paolo Bonzini wrote:
> >>>> I would just patch OVMF to ignore the RSDT if there is an XSDT.
> >>>>
> >>>> Alternatively, can you check for ACPI 2.0 support via _OSI, and load the ACPI 2.0 bits via LoadTable? Hopefully XP does not BSOD if the invalid (for ACPI 1.0) opcodes are in a Then block or in a separate method... Then you can use just an RSDT.
> >>>>
> >>>> Paolo
> >>>
> >>>
> >>> So it's even easier. The following doesn't crash XP:
> >>>
> >>> Method(ADDR, 0, Serialized) {
> >>> /* Region is local to method to avoid crashing ACPI 1.0 guests */
> >>> DataTableRegion(IDPT, "UEFI", "BXPC", "VMGENI");
> >>> Field (IDPT, AnyAcc, NoLock, Preserve) {
> >>> Offset (54),
> >>> VGIA, 64 // address of "etc/acpi/vmgenid" blob
> >>> }
> >>> Return(Add(VGIA), 40);
> >>> }
> >>>
> >>> Simply because XP doesn't ever call ADDR.
> >>> Method must be serialized since attempts to create two
> >>> regions or fields with the same name would crash OSPM.
> >>
> >> That sounds like a huge relief to me, so thank you for researching it.
> >>
> >> Laszlo
> >
> > Mind you, I still think it's worth it to support XSDT eventually,
> > but the immediate need to do this in 2.4 timeframe is gone.
>
> ... I'll have to make the OVMF linker/loader a little bit smarter, so
> that this QEMU patch series doesn't break it. Because, unfortunately,
> XSDT seems to be a hard requirement for DataTableRegion(), according to
> the ACPI spec. (Thus, unless SeaBIOS installs an XSDT too,
> DataTableRegion() may not work in the ADDR method of the vmgenid device.)
That's not really true. ACPI is simply pushing XSDT everywhere,
you will find it hardly ever mentions legacy tables like RSDP anymore.
And in practice, this works fine with all existing guests.
So yes let's do it, but no, don't make this a dependency of
this series.
> (FWIW I checked the ACPICA source, and AFAICS, DataTableRegion() *of
> ACPICA* should locate tables from the RSDT too just fine. But, IIRC,
> Windows does not use ACPICA, and the ACPI spec requires XSDT. Quite
> unfortunate.)
>
> The idea I have for OVMF is to track the offsets for each blob from
> which tables have been installed already. Then I can detect further
> pointers (located in any other blobs) pointing to the same offsets, and
> forego duplicate table installations. This should fix the problem I
> reported in this thread, and then this patch set should work for OVMF too.
>
> ... I've come across this today while writing "docs/specs/vmgenid.txt".
>
> Laszlo
next prev parent reply other threads:[~2015-08-27 17:58 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-08 18:14 [Qemu-devel] [PATCH v2 0/4] acpi: xsdt support Michael S. Tsirkin
2015-06-08 18:14 ` [Qemu-devel] [PATCH v2 1/4] acpi: add API for 64 bit offsets Michael S. Tsirkin
2015-06-08 18:14 ` [Qemu-devel] [PATCH v2 2/4] i386/acpi: collect 64 bit offsets for xsdt Michael S. Tsirkin
2015-06-08 18:14 ` [Qemu-devel] [PATCH v2 3/4] i386/acpi: add XSDT Michael S. Tsirkin
2015-06-08 18:14 ` [Qemu-devel] [PATCH v2 4/4] acpi: unify rsdp generation Michael S. Tsirkin
2015-06-09 0:08 ` [Qemu-devel] [PATCH v2 0/4] acpi: xsdt support Laszlo Ersek
2015-06-09 5:31 ` Michael S. Tsirkin
2015-06-09 6:02 ` Paolo Bonzini
2015-06-09 6:35 ` Michael S. Tsirkin
2015-06-09 6:38 ` Michael S. Tsirkin
2015-06-09 7:41 ` Laszlo Ersek
2015-06-09 8:34 ` Michael S. Tsirkin
2015-06-09 14:01 ` Laszlo Ersek
2015-06-09 9:39 ` Igor Mammedov
2015-06-09 9:10 ` Michael S. Tsirkin
2015-06-09 9:49 ` Michael S. Tsirkin
2015-06-09 14:02 ` Laszlo Ersek
2015-06-09 14:05 ` Michael S. Tsirkin
2015-08-27 14:27 ` Laszlo Ersek
2015-08-27 17:58 ` Michael S. Tsirkin [this message]
2015-08-28 6:23 ` Laszlo Ersek
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=20150827205706-mutt-send-email-mst@redhat.com \
--to=mst@redhat.com \
--cc=ghammer@redhat.com \
--cc=imammedo@redhat.com \
--cc=lersek@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=shannon.zhao@linaro.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).