[Qemu-devel] [edk2 PATCH 0/1] OvmfPkg: grab ACPI tables from QEMU

[Laszlo Ersek]

I'll put only some testing and usage notes in the blurb. The commit
message for the patch and the comment block in the code go into some
implementation detail.

First, this patch has no guest-visible consequences when upgrading from
qemu v1.6 or earlier to v1.7 or later, as long as the qemu machine type
(-M option) is kept intact. Qemu only makes the underlying feature
available for v1.7+ machine types available.

(The machine type is saved in the libvirt XML, so libvirt users are
automatically protected. Direct qemu users need to specify a machine
type with an exact version number.)

Second, I tested the patch under the following circumstances:
- 3.10-based host kernel,
- qemu v1.7.0-rc0, with additional patches that shrink the "pci-hole"
  memory range to just below "system.flash" (see the parallel discussion
  on qemu-devel),
- in the guest, OVMF from SVN r14831, with the following additional
  patches pending on edk2-devel:
  - [edk2] [PATCH v2 00/10] OVMF support for QEMU's PC System Flash
  - [edk2] [PATCH v3 0/2] OvmfPkg: don't restore NvVars from disk if we
    have working flash
  - (this patch)

Guest OSes:
(1) RHEL-7,
(2) Windows Server 2008 R2 SP1 (using additional CSM patches for OVMF),
(3) Windows Server 2012 R2

Details:

(1) RHEL-7

No noticeable changes in behavior.

I dumped and decompiled all ACPI tables before and after the patch. I
also saved the dmesgs. I can make them available at request.

I compared these. I noticed the following differences:

- OEM strings in tables (of course).

- Other small, apparently insignificant changes (for example, in the
  MADT the OVMF built-in tables set the ID of the IO-APIC to
  num_vcpus+1, while qemu exports it as a fixed 0 value, same as SeaBIOS
  used to prepare it). Similarly C[23] latencies in FADT (=FACP). OVMF
  also used to export a bunch of fixed fluff in FADT, which is now gone
  if we take the tables from qemu.

- Important stuff like PCI interrupt routing (_PRT, LNK[A-DS]) seems
  identical, according to the guest kernel dmesg.

- One small regression where OVMF used to provide RESET_REG in FADT
  (=FACP), but qemu currently doesn't say so. Should be fixed in qemu,
  probably.

- Giant leaps forward in the DSDT/SSDT area, especially wrt. PCI
  hotplug. (I didn't actually test PCI hotplug, that's for another
  time.)

- The S3/S4 packages are functionally identical. (Of course OVMF doesn't
  support S3 yet, that's a whole different story.)

- Qemu by default exports a HPET table. The base address described
  therein (0xFED00000) matches the fixed values we have in
  "OvmfPkg/PlatformPei/Platform.c" and
  "PcAtChipsetPkg/PcAtChipsetPkg.dec". I'll return to the HPET later.

- Boot progress bar and console (efifb) continue to work (tested with
  both 1GB and 5GB guest sizes).

(2) Windows Server 2008 R2 SP1 (using additional CSM patches for OVMF)

No changes that would have been visible to me as an interactive user.
Shutdown with the ACPI power button works.

(3) Windows Server 2012 R2

Installed a brand new VM for this guest.

It worked OK but at several points that all looked like reboot attempts
(even after installation, with the live OS) the VM was just waiting and
waiting for something to happen. I looked into the KVM trace as Gleb
had taught me, and I noticed accesses to the HPET. Which made me recall
(and google, and find) recommendations to disable the HPET in general
for virtual machines.

(Again, the OVMF built-in tables don't mention HPET at all, but qemu
does export one if the -no-hpet switch is absent.)

So, I added the corresponding stanza to my libvirt XML. It helped some,
but the problem didn't go away completely.

At this point the KVM trace overwhelmed me, and I just flipped the
machine type back to pc-i440fx-1.6. (I verified in the OVMF debug log
that this had the desired effect -- no tables from qemu.)

The hangs were gone. So I flipped the machine type to pc-i440fx-1.7
again, just to triple-check -- and I couldn't reproduce the hangs any
longer!

So, my testing in this part is inconclusive. The problem may or may not
be related to the ACPI tables; it might or might not be related to
recent changes in qemu itself, etc. Someone with more time and knowledge
than I have should look into the KVM trace.

The ACPI power button initiates the shutdown sequence.

Bonus testing: verified secure boot in this guest with the Microsoft
keys. Thanks to Jordan's series "OVMF support for QEMU's PC System
Flash" mentioned above, key enrollment is permanent now.

Thanks,
Laszlo

Laszlo Ersek (1):
  OvmfPkg/AcpiPlatformDxe: download ACPI tables from QEMU

 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.h |   7 +-
 OvmfPkg/AcpiPlatformDxe/AcpiPlatform.c |  12 +-
 OvmfPkg/AcpiPlatformDxe/Qemu.c         | 204 +++++++++++++++++++++++++++++++++
 3 files changed, 215 insertions(+), 8 deletions(-)

-- 
1.8.3.1