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
