Re: [Qemu-devel] [Linaro-acpi] [RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

[Gerd Hoffmann]

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:
> > 
> > address@hidden ~]# 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