On Mon, Oct 08, 2012 at 11:35:15PM -0400, Jason Baron wrote:
From: Jason Baron jbaron@redhat.com
This builds seabios such that the dsdt tables are no longer built into the seabios binary. They must be passed to the seabios via fw_cfg. This saves space in the seabios binary for unnecessary dsdt tables.
I suspect that this will make other users of Seabios, besides qemu unhappy, but I'm not sure.
Only qemu/kvm uses the acpi support in seabios. (If one excludes bochs which hasn't really used seabios.) Coreboot and Xen both deploy acpi completely separately from seabios.
Instead of moving just the dsdt to qemu, though, can we move all acpi tables into qemu? Moving just the dsdt can lead to conflicts with the generated ssdt code and potentially some of the other acpi tables.
The only seabios acpi dependency that pops into mind is the memory addresses of the acpi tables themselves. It should be trivial to have seabios create the rsdt/rsdp while pulling all the remaining acpi tables from qemu via fw_cfg. Almost all the tables in acpi describe hardware and not the firmware. Are there other cases where the firmware needs to have input when generating the contents of an acpi table?
-Kevin
On Tue, Oct 09, 2012 at 08:04:12PM -0400, Kevin O'Connor wrote:
On Mon, Oct 08, 2012 at 11:35:15PM -0400, Jason Baron wrote:
From: Jason Baron jbaron@redhat.com
This builds seabios such that the dsdt tables are no longer built into the seabios binary. They must be passed to the seabios via fw_cfg. This saves space in the seabios binary for unnecessary dsdt tables.
I suspect that this will make other users of Seabios, besides qemu unhappy, but I'm not sure.
Only qemu/kvm uses the acpi support in seabios. (If one excludes bochs which hasn't really used seabios.) Coreboot and Xen both deploy acpi completely separately from seabios.
Instead of moving just the dsdt to qemu, though, can we move all acpi tables into qemu? Moving just the dsdt can lead to conflicts with the generated ssdt code and potentially some of the other acpi tables.
The only seabios acpi dependency that pops into mind is the memory addresses of the acpi tables themselves. It should be trivial to have seabios create the rsdt/rsdp while pulling all the remaining acpi tables from qemu via fw_cfg. Almost all the tables in acpi describe hardware and not the firmware. Are there other cases where the firmware needs to have input when generating the contents of an acpi table?
There is a BDAT OperationRegion that points to memory allocated by Seabios.
-- Gleb.
On Wed, Oct 10, 2012 at 09:05:11AM +0200, Gleb Natapov wrote:
On Tue, Oct 09, 2012 at 08:04:12PM -0400, Kevin O'Connor wrote:
On Mon, Oct 08, 2012 at 11:35:15PM -0400, Jason Baron wrote:
From: Jason Baron jbaron@redhat.com
This builds seabios such that the dsdt tables are no longer built into the seabios binary. They must be passed to the seabios via fw_cfg. This saves space in the seabios binary for unnecessary dsdt tables.
I suspect that this will make other users of Seabios, besides qemu unhappy, but I'm not sure.
Only qemu/kvm uses the acpi support in seabios. (If one excludes bochs which hasn't really used seabios.) Coreboot and Xen both deploy acpi completely separately from seabios.
Instead of moving just the dsdt to qemu, though, can we move all acpi tables into qemu? Moving just the dsdt can lead to conflicts with the generated ssdt code and potentially some of the other acpi tables.
The only seabios acpi dependency that pops into mind is the memory addresses of the acpi tables themselves. It should be trivial to have seabios create the rsdt/rsdp while pulling all the remaining acpi tables from qemu via fw_cfg. Almost all the tables in acpi describe hardware and not the firmware. Are there other cases where the firmware needs to have input when generating the contents of an acpi table?
There is a BDAT OperationRegion that points to memory allocated by Seabios.
All the info passed via BDAT is available in QEMU. Granted, a method other than BDAT would be needed to pass the info, but that should not be difficult.
-Kevin
Hi,
Instead of moving just the dsdt to qemu, though, can we move all acpi tables into qemu? Moving just the dsdt can lead to conflicts with the generated ssdt code and potentially some of the other acpi tables.
For now the plan is to keep the dsdt in the seabios git repo, but install them next to bios.bin, then have qemu pick the correct one depending on the machine type.
The only seabios acpi dependency that pops into mind is the memory addresses of the acpi tables themselves.
There is also the BDAT in the SSDT and the patching logic ...
cheers, Gerd
Il 10/10/2012 09:14, Gerd Hoffmann ha scritto:
Hi,
Instead of moving just the dsdt to qemu, though, can we move all acpi tables into qemu? Moving just the dsdt can lead to conflicts with the generated ssdt code and potentially some of the other acpi tables.
For now the plan is to keep the dsdt in the seabios git repo, but install them next to bios.bin, then have qemu pick the correct one depending on the machine type.
The only seabios acpi dependency that pops into mind is the memory addresses of the acpi tables themselves.
There is also the BDAT in the SSDT and the patching logic ...
The patching logic can be moved to QEMU with no problems. The BDAT perhaps could be replaced with a Package and Index().
I think there's no urgency to move ACPI tables to QEMU, but it would be a useful cleanup if somebody has the time to do it. It would improve the degree to which compatibility machine types can mimic old versions of QEMU, too.
The important thing is that it can be done incrementally. Even the SSDT can be split in multiple tables, one built by QEMU and one built by SeaBIOS.
Laszlo has been forward-porting some SeaBIOS changes to TianoCore. When he gets to the remaining bells-and-whistles (mostly hotplug and S3/S4), perhaps he could instead add the fwcfg interface to TianoCore and move them from SeaBIOS to QEMU. IIUC it's just a sequence of
uint16_t len; uint8_t table[];
structs, it shouldn't take long to add it.
Paolo
(CC'ing Jordan, the TianoCore/OvmfPkg maintainer)
On 10/10/12 09:29, Paolo Bonzini wrote:
Il 10/10/2012 09:14, Gerd Hoffmann ha scritto:
Hi,
Instead of moving just the dsdt to qemu, though, can we move all acpi tables into qemu? Moving just the dsdt can lead to conflicts with the generated ssdt code and potentially some of the other acpi tables.
For now the plan is to keep the dsdt in the seabios git repo, but install them next to bios.bin, then have qemu pick the correct one depending on the machine type.
The only seabios acpi dependency that pops into mind is the memory addresses of the acpi tables themselves.
There is also the BDAT in the SSDT and the patching logic ...
The patching logic can be moved to QEMU with no problems. The BDAT perhaps could be replaced with a Package and Index().
I think there's no urgency to move ACPI tables to QEMU, but it would be a useful cleanup if somebody has the time to do it. It would improve the degree to which compatibility machine types can mimic old versions of QEMU, too.
The important thing is that it can be done incrementally. Even the SSDT can be split in multiple tables, one built by QEMU and one built by SeaBIOS.
Laszlo has been forward-porting some SeaBIOS changes to TianoCore. When he gets to the remaining bells-and-whistles (mostly hotplug and S3/S4), perhaps he could instead add the fwcfg interface to TianoCore and move them from SeaBIOS to QEMU. IIUC it's just a sequence of
uint16_t len; uint8_t table[];
structs, it shouldn't take long to add it.
Good idea. See the following edk2-devel messages from April 2012:
http://sourceforge.net/mailarchive/message.php?msg_id=29200341 http://sourceforge.net/mailarchive/message.php?msg_id=29200817
I added this to my todo list. I don't know when I'll get to it, so if someone needs it urgently, please go ahead. (Especially the seabios->qemu move could be implemented while I'm slacking off :))
Thanks, Laszlo
-
Gerd Hoffmann -
Gleb Natapov -
Kevin O'Connor -
Laszlo Ersek -
Paolo Bonzini