[Qemu-devel] "Using Python to investigate EFI and ACPI"

[Laszlo Ersek]

Hi Josh,

I just found the LWN.net article with the title in the subject:

  http://lwn.net/SubscriberLink/655992/04701db2bbb7e716/

("Thank you LWN", of course. :))

This got me kind of excited. In your presentation, according to the
article, you were using KVM and OVMF to showcase the ACPI features of
"BITS". Further, in

  http://biosbits.org/scripting/

you write, "You can also find arbitrary ACPI objects by path, and
evaluate arbitrary ACPI methods, with the return value decoded into a
Python object".

I'm excited because for virtualization we might have the reverse use
case: use BITS to test / debug / develop the ACPI generator of QEMU. :)

As you may now, QEMU generates almost all of its ACPI tables
dynamically, providing the guest with an "ACPI payload" that describes
the actual virtual hardware as accurately as possible.

Then this payload is passed to the guest firmware (SeaBIOS or OVMF) over
"fw_cfg" (which is a simple protocol, comprising, at this point, one
selector and one data register, which are IO ports or MMIO locations --
see "docs/specs/fw_cfg.txt" in QEMU and
"Documentation/devicetree/bindings/arm/fw-cfg.txt" in the kernel).

The guest firmware downloads the "ACPI payload" over fw_cfg, does some
generic processing on them (we call this the "ACPI linker/loader
script"), and ultimately installs the ACPI tables in a way that is
appropriate for the firmware in question.

To be more concrete, the tables you investigated in your presentation
with BITS were generated (very roughly) by the following files in QEMU:

  hw/acpi/aml-build.c
  hw/acpi/bios-linker-loader.c
  hw/acpi/...
  hw/i386/acpi-build.c

and processed and installed by the following source file in edk2:

  OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpi.c

With this background, you can probably see where I'm going with this. It
is not really easy to *test* the AML methods that QEMU generates
(piecing them together, with helper functions, from AML primitives),
without dedicated guest kernel drivers. I think the only method that I
know of is the following:

- in the Linux guest, dump the ACPI tables with acpidump, or save them
from sysfs directly (/sys/firmware/acpi/tables)
- pass the DSDT and the SSDTs (and any data tables referenced by them?)
to AcpiExec from the ACPICA suite
- work with AcpiExec

But, for simple testing, can we maybe run your tool within the guest,
before the runtime OS boots?

Although AcpiDump is being ported to edk2:

  http://thread.gmane.org/gmane.comp.bios.edk2.devel/1109

I'm unsure if it will be able to evaluate / execute AML methods. (If it
parallels the "acpidump" utility we have on GNU/Linux distros, it won't.)

Thus it would be awesome if we had some AcpiExec-like functionality
early on in the guest (for example in the form of a UEFI Shell
application, or as a python tool that runs within the edk2 Python port,
or even in grub).

For example, assume your runtime guest OS is Windows (with its picky,
closed-source ACPI interpreter); you make a change in QEMU's ACPI
generator, rebuild QEMU, reboot the guest, drop to the UEFI shell to
verify the change "by eye", exit the shell, and *then* continue booting
Windows. (Which will hopefully not BSOD at that point, after the
verification with BITS / AcpiExec etc.)

So, I have three questions:

(1) What is the relationship between the ACPI facility of BITS, and ACPICA?

(2) Is there a bit more comprehensive documentation about the ACPI
module of BITS? AcpiExec and the ACPICA Debugger have quite indulged me
with their incredible documentation (documents/acpica-reference.pdf). It
would be great if BITS' ACPI module had a list of commands, to see what
is there to play with.

(3) I should mention that QEMU generates ACPI also for arm/aarch64
virtual machines ("hw/arm/virt-acpi-build.c" in QEMU), and the same edk2
module as noted above (built for arm/aarch64) does the guest side
processing. Do you think it's possible to use BITS in arm/aarch64 VMs?

... I apologize if tools / documentation already exist for this kind of
development work; everyone please educate me then. I hope my questions
make at least some sense; I realize this email isn't well organized.

Thanks
Laszlo