From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2D8W-0006tw-GT for qemu-devel@nongnu.org; Tue, 09 Jun 2015 02:35:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2D8Q-0005Gg-Ox for qemu-devel@nongnu.org; Tue, 09 Jun 2015 02:35:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46332) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2D8Q-0005FN-EX for qemu-devel@nongnu.org; Tue, 09 Jun 2015 02:35:42 -0400 Date: Tue, 9 Jun 2015 08:35:38 +0200 From: "Michael S. Tsirkin" Message-ID: <20150609083521-mutt-send-email-mst@redhat.com> References: <1433787255-4372-1-git-send-email-mst@redhat.com> <55762E63.7010606@redhat.com> <20150609072936-mutt-send-email-mst@redhat.com> <964733846.17699064.1433829751766.JavaMail.zimbra@zmail13.collab.prod.int.phx2.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <964733846.17699064.1433829751766.JavaMail.zimbra@zmail13.collab.prod.int.phx2.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 0/4] acpi: xsdt support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: ghammer@redhat.com, imammedo@redhat.com, lersek@redhat.com, qemu-devel@nongnu.org, shannon.zhao@linaro.org 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. >=20 > Alternatively, can you check for ACPI 2.0 support via _OSI, and load th= e 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... The= n you can use just an RSDT. >=20 > Paolo It does BSOD. Skipping RSDT sounds good. >=20 > -----Original Message----- > From: Michael S. Tsirkin [mst@redhat.com] > Received: marted=EC, 09 giu 2015, 7:31 > To: Laszlo Ersek [lersek@redhat.com] > CC: qemu-devel@nongnu.org, ghammer@redhat.com, pbonzini@redhat.com, sha= nnon.zhao@linaro.org, imammedo@redhat.com > Subject: Re: [PATCH v2 0/4] acpi: xsdt support >=20 > On Tue, Jun 09, 2015 at 02:08:03AM +0200, Laszlo Ersek wrote: > > On 06/08/15 20:14, Michael S. Tsirkin wrote: > > > XSDT support allows using ACPI 2 features while > > > avoiding breaking legacy windows XP guests: > > > ACPI 2 tables are linked from XSDT only, > > > ACPI 1 tables from both RSDT and XSDT, this way > > > XP does not see ACPI 2 tables. > > >=20 > > > As a first step, this patchset generates v2 RSDP > > > and fills in XSDT matching RSDT exactly. > > >=20 > > > ARM can switch to XSDT as well, I'm not bothering > > > until there's an easy way to test that. > > >=20 > > > Note: unit test files need to be updated with this, > > > I'm not bothering with posting them. > > >=20 > > > Changes from v1: > > > xsdt address is 64 bit > > > arm patch is now tested > > >=20 > > > Michael S. Tsirkin (4): > > > acpi: add API for 64 bit offsets > > > i386/acpi: collect 64 bit offsets for xsdt > > > i386/acpi: add XSDT > > > acpi: unify rsdp generation > > >=20 > > > include/hw/acpi/acpi-defs.h | 15 +++++-- > > > include/hw/acpi/aml-build.h | 7 +++- > > > hw/acpi/aml-build.c | 99 +++++++++++++++++++++++++++++++++= ++++-------- > > > hw/arm/virt-acpi-build.c | 39 +++--------------- > > > hw/i386/acpi-build.c | 64 +++++++++++------------------ > > > 5 files changed, 129 insertions(+), 95 deletions(-) > > >=20 > >=20 > > I tested this series with ArmVirtQemu (aka AAVMF) and OVMF too. (They > > use common code in edk2.) > >=20 > > The ARM build works indeed, but that's only because in patch #4 we ha= ve > >=20 > > build_rsdp(tables->rsdp, tables->linker, rsdt, 0); > >=20 > > ie. there's only an RSDT. > >=20 > > Due to patch #3 however, the OVMF client breaks: > >=20 > > build_rsdp(tables->rsdp, tables->linker, rsdt, xsdt); > >=20 > > The problem is that the "directed acyclic graph" of ADD_POINTER edges= is > > no longer a tree. At least some tables can be reached on multiple pat= hs. > > (Eg. the FADT can be reached via RSDP->RSDT-> FADT, and also > > RSDP->XSDT->FADT.) > >=20 > > This is a problem because EFI_ACPI_TABLE_PROTOCOL has "builtin > > knowledge" about what tables may not be installed only once vs. sever= al > > times. Unfortunately, in this case both decisions have bad consequenc= es: > >=20 > > - When FADT is passed to EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() f= or > > the second time, the function returns EFI_ACCESS_DENIED, and the > > linker/loader client bails out. > >=20 > > - When (eg.) the same SSDT is passed to > > EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() for the second time, the > > function will happily install (a copy of) it again, and then we'll en= d > > up with two copies of the same SSDT. > >=20 > > EFI_ACPI_TABLE_PROTOCOL manages both the RSDT and the XSDT internally= . > > As far as I can see, it puts each table in both. The RSDT and the XSD= T > > are not distinguished even on the UEFI spec level; it lumps them > > together under "RSDT/XSDT" every time. > >=20 > > This is probably very frustrating; sorry about that. > >=20 > > Laszlo >=20 > Thanks for the info! This is worth fixing. Can you fix this without > protocol changes, or should we change the protocol to pass a hint that = a > pointer is to another instance of a previously used table? >=20 > --=20 > MST