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

[Laszlo Ersek <lersek@redhat.com>]

On 06/09/15 10:34, Michael S. Tsirkin wrote:
> On Tue, Jun 09, 2015 at 09:41:20AM +0200, Laszlo Ersek wrote:
>> 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.
> 
> That's what I was going to ask. Can XP boot on UEFI somehow?

Only if OVMF is built with the SeaBIOS Compatibility Support Module. But
then it still qualifies as a legacy boot. (Ie. the OS will still exist
in a legacy BIOS environment.)

A CSM build of OVMF is available in Gerd's repo, but the internal
UEFI-to-CSM interface is nightmarish enough that I wasn't willing to
support it in RHEL, so we won't do that. The argument being, if you need
a legacy OS, just pick SeaBIOS as your guest firmware; in virt it's
easy to choose your firmware.

Thanks
Laszlo

> 
>> * 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
>