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
