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

[Gerd Hoffmann <kraxel@redhat.com>]

  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