From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2C8G-0003lU-2q for qemu-devel@nongnu.org; Tue, 09 Jun 2015 01:31:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z2C8C-0002Gu-Nc for qemu-devel@nongnu.org; Tue, 09 Jun 2015 01:31:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z2C8C-0002GS-GQ for qemu-devel@nongnu.org; Tue, 09 Jun 2015 01:31:24 -0400 Date: Tue, 9 Jun 2015 07:31:20 +0200 From: "Michael S. Tsirkin" Message-ID: <20150609072936-mutt-send-email-mst@redhat.com> References: <1433787255-4372-1-git-send-email-mst@redhat.com> <55762E63.7010606@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55762E63.7010606@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 0/4] acpi: xsdt support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: ghammer@redhat.com, pbonzini@redhat.com, imammedo@redhat.com, qemu-devel@nongnu.org, shannon.zhao@linaro.org 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. > > > > As a first step, this patchset generates v2 RSDP > > and fills in XSDT matching RSDT exactly. > > > > ARM can switch to XSDT as well, I'm not bothering > > until there's an easy way to test that. > > > > Note: unit test files need to be updated with this, > > I'm not bothering with posting them. > > > > Changes from v1: > > xsdt address is 64 bit > > arm patch is now tested > > > > 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 > > > > 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(-) > > > > I tested this series with ArmVirtQemu (aka AAVMF) and OVMF too. (They > use common code in edk2.) > > The ARM build works indeed, but that's only because in patch #4 we have > > build_rsdp(tables->rsdp, tables->linker, rsdt, 0); > > ie. there's only an RSDT. > > Due to patch #3 however, the OVMF client breaks: > > build_rsdp(tables->rsdp, tables->linker, rsdt, xsdt); > > 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 paths. > (Eg. the FADT can be reached via RSDP->RSDT-> FADT, and also > RSDP->XSDT->FADT.) > > This is a problem because EFI_ACPI_TABLE_PROTOCOL has "builtin > knowledge" about what tables may not be installed only once vs. several > times. Unfortunately, in this case both decisions have bad consequences: > > - When FADT is passed to EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() for > the second time, the function returns EFI_ACCESS_DENIED, and the > linker/loader client bails out. > > - 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 end > up with two copies of the same SSDT. > > 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 XSDT > are not distinguished even on the UEFI spec level; it lumps them > together under "RSDT/XSDT" every time. > > This is probably very frustrating; sorry about that. > > Laszlo 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? -- MST