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 >