From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39463) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z275R-0002QH-6t for qemu-devel@nongnu.org; Mon, 08 Jun 2015 20:08:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z275N-0000r8-KO for qemu-devel@nongnu.org; Mon, 08 Jun 2015 20:08:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44747) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z275N-0000qd-Eo for qemu-devel@nongnu.org; Mon, 08 Jun 2015 20:08:09 -0400 Message-ID: <55762E63.7010606@redhat.com> Date: Tue, 09 Jun 2015 02:08:03 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1433787255-4372-1-git-send-email-mst@redhat.com> In-Reply-To: <1433787255-4372-1-git-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 0/4] acpi: xsdt support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , qemu-devel@nongnu.org Cc: ghammer@redhat.com, pbonzini@redhat.com, shannon.zhao@linaro.org, imammedo@redhat.com 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