[Qemu-devel] qemu / seabios ACPI table interface

[Qemu-devel] qemu / seabios ACPI table interface

[Laszlo Ersek]

I'm confused. What are the requirements?

(1) should unpatched qemu work with patched seabios?
(2) should patched qemu work with unpatched seabios?

Considering patched qemu + patched seabios,
(3) should qemu dynamically control table origin/contents per table?
(4) should qemu be able to suppress/disable a seabios table via fw_cfg
without providing a replacement?

I had thought:
(1) yes (firmware upgrade on same hardware),
(2) no (hardware upgrade),
(3) yes (eases development and ultimately covers everything),
(4) no (*)

but apparently I'm wrong. I'm ready to be enlightened and try to
implement whatever the consensus is, but what is the consensus?

(*) For each table we can investigate why SeaBIOS provides it now:

- RSDP, RSDT, XSDT: These look like links-only tables. In general, links
(pointers) have to be updated by the firmware (eg. in the FADT), thus
qemu would provide zeros in those fields in general. Since these three
tables consist of nothing more than pointers, qemu would never provide
any of these tables. Choice between RSDT and XSDT is the jurisdiction of
the boot firmware, and it should choose exactly one. (SeaBIOS currently
uses RSDT, OVMF uses XSDT.)

- FADT (FACP): required by the spec. Qemu would either put up with
SeaBIOS's or provide a replacement.

- FACS: always prepared by the boot firmware.

- DSDT: Same as FADT.

- SSDT: a continuation of the DSDT; there can be several instances. If
the DSDT comes from qemu, SeaBIOS shouldn't install any SSDTs of its
own. Qemu won't provide SSDTs without its own DSDT.

- APIC (MADT): required in the "APIC interrupt model", which is probably
"always" for us. Hence same as with FADT/DSDT.

- HPET: Hardware dependent. If qemu doesn't provide the hardware, it
also wouldn't provide the table, and SeaBIOS already doesn't install one
itself because there's no hardware. If the hardware is there, qemu
provides the table, or puts up with SeaBIOS's.

- SRAT: Dependent on NUMA setup. Same case as with HPET.

- MCFG: Seems to depend on hardware (q35). Same as with HPET.

(I'll be out of the office next week -- if I don't follow up, that's the
reason.)

Thanks
Laszlo

Re: [Qemu-devel] qemu / seabios ACPI table interface

[Paolo Bonzini]

Il 22/03/2013 17:09, Laszlo Ersek ha scritto:
> I'm confused. What are the requirements?
> 
> (1) should unpatched qemu work with patched seabios?

Yes.

> (2) should patched qemu work with unpatched seabios?

No.

> Considering patched qemu + patched seabios,
> (3) should qemu dynamically control table origin/contents per table?

Not sure I understand this?

> (4) should qemu be able to suppress/disable a seabios table via fw_cfg
> without providing a replacement?

QEMU should be able to suppress all SeaBIOS tables except for the four
tables you identified.  Once the transition is done, a special fw_cfg
file (or alternatively a SeaBIOS/OVMF patch) would direct SeaBIOS to not
create _any_ ACPI table except those four.

> I had thought:
> (1) yes (firmware upgrade on same hardware),
> (2) no (hardware upgrade),
> (3) yes (eases development and ultimately covers everything),
> (4) no (*)

Three out of four, you're probably right on (3) too. :)

Paolo

> but apparently I'm wrong. I'm ready to be enlightened and try to
> implement whatever the consensus is, but what is the consensus?
> 
> (*) For each table we can investigate why SeaBIOS provides it now:
> 
> - RSDP, RSDT, XSDT: These look like links-only tables. In general, links
> (pointers) have to be updated by the firmware (eg. in the FADT), thus
> qemu would provide zeros in those fields in general. Since these three
> tables consist of nothing more than pointers, qemu would never provide
> any of these tables. Choice between RSDT and XSDT is the jurisdiction of
> the boot firmware, and it should choose exactly one. (SeaBIOS currently
> uses RSDT, OVMF uses XSDT.)
> 
> - FADT (FACP): required by the spec. Qemu would either put up with
> SeaBIOS's or provide a replacement.
> 
> - FACS: always prepared by the boot firmware.
> 
> - DSDT: Same as FADT.
> 
> - SSDT: a continuation of the DSDT; there can be several instances. If
> the DSDT comes from qemu, SeaBIOS shouldn't install any SSDTs of its
> own. Qemu won't provide SSDTs without its own DSDT.
> 
> - APIC (MADT): required in the "APIC interrupt model", which is probably
> "always" for us. Hence same as with FADT/DSDT.
> 
> - HPET: Hardware dependent. If qemu doesn't provide the hardware, it
> also wouldn't provide the table, and SeaBIOS already doesn't install one
> itself because there's no hardware. If the hardware is there, qemu
> provides the table, or puts up with SeaBIOS's.
> 
> - SRAT: Dependent on NUMA setup. Same case as with HPET.
> 
> - MCFG: Seems to depend on hardware (q35). Same as with HPET.
> 
> (I'll be out of the office next week -- if I don't follow up, that's the
> reason.)
> 
> Thanks
> Laszlo
> 
> 

Re: [Qemu-devel] qemu / seabios ACPI table interface

[Kevin O'Connor]

On Fri, Mar 22, 2013 at 05:09:53PM +0100, Laszlo Ersek wrote:
> I'm confused. What are the requirements?

Here's my suggested implementation:

- Have qemu create the ACPI tables in new fw_cfg "file" entries; one
  "file" per table.  Have QEMU put ACPI tables grouped in /etc/acpi/ -
  for example /etc/acpi/HPET.  Have QEMU submit the PIR in /etc/pir,
  the mptable in /etc/mptable, and the smbios table in /etc/smbios.

- For ACPI, have QEMU create RSDT, XSDT, FADT, FACS tables and pass
  them through via fw_cfg entries (just like it would the other ACPI
  tables).  SeaBIOS can update the memory pointers in the
  RSDT/XSDT/FADT to make them correct.  SeaBIOS can generate the RSDP
  (with the same signature as the RSDT/XSDT) on its own.  The reason I
  think QEMU should generate the RSDT and/or XSDT is it allows QEMU to
  control the table signatures and whether or not XSDT should be
  present.

- We can create a development version of seabios that will deploy the
  new fw_cfg entries for testing purposes.  This code can even
  mix-and-match with the existing seabios tables.  We can also do
  binary comparison between new and old for testing.  This seabios
  code need not be in the official seabios repo as it will only be
  needed by developers working on implementing and testing the new
  qemu code during the transition.

- Work through the merge process to get the table generation code
  added into qemu mainline.

- Once the tables are all provided by QEMU (or at least one table set
  - for example smbios), then update the official seabios repo to use
  those tables exclusively from QEMU.  That is, if /etc/mptable is
  present then SeaBIOS would use that and not generate it's own
  mptable.  If any file exists in /etc/acpi/ then SeaBIOS would only
  use tables from that directory and not generate any acpi tables.

- Finally, update QEMU to use the latest seabios rev.

> (1) should unpatched qemu work with patched seabios?
> (2) should patched qemu work with unpatched seabios?
> 
> Considering patched qemu + patched seabios,
> (3) should qemu dynamically control table origin/contents per table?
> (4) should qemu be able to suppress/disable a seabios table via fw_cfg
> without providing a replacement?

With the above plan the answers to these questions would be: yes, yes,
yes, yes.

-Kevin