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
