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

["Michael S. Tsirkin" <mst@redhat.com>]

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?

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