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
> 
>