qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 0/4] acpi: xsdt support


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v2 0/4] acpi: xsdt support
Date: Thu, 27 Aug 2015 20:58:31 +0300

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]