Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support

From: Paolo Bonzini <pbonzini@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>,
	Phil Dennis-Jordan <lists@philjordan.eu>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>,
	ehabkost@redhat.com, "seabios@seabios.org" <seabios@seabios.org>,
	"qemu-devel@nongnu.org qemu-devel" <qemu-devel@nongnu.org>,
	Programmingkid <programmingkidx@gmail.com>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Igor Mammedov <imammedo@redhat.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] Commit 77af8a2b95b79699de650965d5228772743efe84 breaks Windows 2000 support
Date: Wed, 26 Jul 2017 14:06:38 +0200	[thread overview]
Message-ID: <4c8a6dc2-7732-1dd3-982a-f39b3fe69e11@redhat.com> (raw)
In-Reply-To: <f9db34d0-759a-c2f4-d8a5-9bddd79cca4b@redhat.com>

On 26/07/2017 13:42, Laszlo Ersek wrote:
> Not exactly; the PCD controls whether the EFI_ACPI_TABLE_PROTOCOL will
> expose an RSDT, an XSDT, or both (with matching contents).

You're right that the code does not produce a v1 FADT, I mis-skimmed the
awful code of AcpiTableDxe.  Though the intentions seems to be there in
the UEFI spec, because UEFI has different GUIDs for ACPI 1.0 and 2.0+
RSDPs---and they need not point to the same tables, even though the ACPI
1.0 RSDP is a subset of the 2.0+ one.

AcpiTableDxe's data structures have an "Rsdp1" field (pointing to
"Rsdt1" and from there to "Fadt1") and an "Rsdp3" field (pointing to
"Xsdt" and optionally "Rsdt3", and from both to "Fadt3").  However:

* Fadt1 and Fadt3 have exactly the same content.

* Rsdt3 doesn't point to Fadt1.

It should be easy to make "Fadt1" a v1 table instead of copying the same
contents to Fadt1 and Fadt3, and to make Rsdt3 point to Fadt1.  The CSM
would just work if edk2 did this; until then Windows 2000 over SeaBIOS
over OVMF remains broken, but I guess that's not that much of an issue.

Anyway, once you take CSM into account, IMHO a firmware solution becomes
preferrable to Kevin's proposals to add a etc/table-loader-legacy (or
similar) file in fw_cfg.

Paolo

> The FADT
> always comes from the specific edk2 platform (i.e., OVMF client code),
> and it is not translated in any way, regardless of the PCD value.
> 
> From "MdeModulePkg/MdeModulePkg.dec":
> 
>>   ## Indicates which ACPI versions are targeted by the ACPI tables exposed to the OS
>>   #  These values are aligned with the definitions in MdePkg/Include/Protocol/AcpiSystemDescriptionTable.h
>>   #   BIT 1 - EFI_ACPI_TABLE_VERSION_1_0B.<BR>
>>   #   BIT 2 - EFI_ACPI_TABLE_VERSION_2_0.<BR>
>>   #   BIT 3 - EFI_ACPI_TABLE_VERSION_3_0.<BR>
>>   #   BIT 4 - EFI_ACPI_TABLE_VERSION_4_0.<BR>
>>   #   BIT 5 - EFI_ACPI_TABLE_VERSION_5_0.<BR>
>>   # @Prompt Exposed ACPI table versions.
>>   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x3E|UINT32|0x0001004c
> The expectation is that the specific edk2 platform overrides this PCD at
> build time (if necessary), and then goes on (at boot time) to install
> ACPI tables -- using EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() -- that
> actually match the PCD setting.