On Do, 2014-11-13 at 11:16 -0700, Al Stone wrote:
On 11/13/2014 01:10 AM, Gerd Hoffmann wrote:
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 [ ... ]
So this is problematic: the PM1a_EVT_BLK and PM1a_CNT_BLK should not exist if hardware reduced mode ACPI is being used;
This is x86 and gives some background on why the "firmware inits hardware -> qemu adjusts addresses in acpi tables -> firmware loads acpi tables via fw_cfg" init sequence is used there.
Figuring whenever you have similar problems / requirements on arm or if you can simply go with static acpi tables is up to you ;)
cheers, Gerd