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

[Laszlo Ersek]

On 06/09/15 08:38, Michael S. Tsirkin wrote:
> On Tue, Jun 09, 2015 at 08:35:38AM +0200, 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
>>
>>
>> It does BSOD.
>> Skipping RSDT sounds good.
> 
> Thought a full fix would be nicer - I suspect we'll have more things like this
> in the future.

* I think I wasn't clear enough in my email. There are two problems. The
first problem is that the current linker/loader client in OVMF passes
the same table twice to EFI_ACPI_TABLE_PROTOCOL, if this patch series is
applied to QEMU. That may be fixable, perhaps in several ways.

However, the second problem is, whatever I give EFI_ACPI_TABLE_PROTOCOL,
it will link a copy of that table into the RSDT *and* the XSDT
automatically and indivisibly. So, if you prepare an SSDT with the
opcode that causes XP to BSOD and link that only into the XSDT, then
after OVMF passes it to EFI_ACPI_TABLE_PROTOCOL (only once), the guest
OS will find it in the RSDT and the XSDT both.

On the other hand XP is not a UEFI operating system, so this might not
matter.

* Not sure what is meant by "skipping RSDT". I'm only following
ADD_POINTER commands. Those commands say "increment the UINT[1248] value
at offset foo in *blob* bar, with the start address of blob baz". I have
no clue what table the incremented pointer lives in, I can only check
what table it (potentially) points to. I already omit passing the RSDT
to EFI_ACPI_TABLE_PROTOCOL when I detect it on the *target* side of a
pointer, but I can't recognize it on the source side.

There is no actual graph traversal in place; I only mentioned the DAG
for illustration. The direct reason is that there are two ADD_POINTER
commands (and two source locations to be incremented, respectively) for
each particular pointed-to (blob, offset).

* What does a full fix mean? ... I'm not sure this is worth the churn.
Same as the user is expected not to boot XP with OVMF as the firmware
(which is a command line / libvirt configuration question), he could
just as well be expected not to configure vmgenid for XP.

Thanks
Laszlo