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
