Hi,
My understanding from an IRC conversation yesterday was that at least some of these ACPI blobs contain data which has to be constructed at the point it is requested (ie is not fixed at the point when QEMU starts up), because OVMF will do:
- startup
- prod some parts of the hardware to configure it
- request ACPI tables via fw_cfg
and the ACPI tables have to reflect the statu of the hardware after OVMF's poking, not before.
It is this:
[root@fedora ~]# cat /proc/ioports [ ... ] 0600-063f : 0000:00:01.3 0600-0603 : ACPI PM1a_EVT_BLK 0604-0605 : ACPI PM1a_CNT_BLK 0608-060b : ACPI PM_TMR 0700-070f : 0000:00:01.3 0700-0707 : piix4_smbus [ ... ] [root@fedora ~]# lspci -vs1.3 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) Subsystem: Red Hat, Inc Qemu virtual machine Flags: medium devsel, IRQ 9 Kernel driver in use: piix4_smbus Kernel modules: i2c_piix4
A bunch of acpi registers are in a hidden pci bar of the piix4 acpi device (likewise on q35). The firmware must map this somewhere, and this must be done pretty early because the firmware uses the acpi pm timer for timekeeping.
The acpi tables have references to the apci registers, so the acpi table content must match the actual register location.
[ q35 only: similar issue with the pci mmconfig xbar ]
So there are three options to solve that:
(1) Use a fixed address. Doable, but takes away some flexibility.
(2) Have qemu define the address locations. Has some nasty initialization order issues. Also would require (a) a paravirtual interface or (b) a acpi table parser in the firmware.
(3) Have firmware define the address location. This is what we did on x86. No paravirt interface needed, the firmware simply programs the registers as it likes, and qemu adapts the acpi tables accordingly.
It wasn't entirely clear to me whether this applies equally to the ARM UEFI setup as to x86 + OVMF,
I think on arm doing (2) is alot easier as DT provides a nice way to pass addresses from qemu to firmware/guest.
cheers, Gerd