[SeaBIOS] [Qemu-devel] qemu / seabios ACPI table interface
kevin at koconnor.net
Sat Mar 23 00:59:00 CET 2013
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
- 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,
More information about the SeaBIOS