On 05/30/13 18:20, Jordan Justen wrote:
I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu.
I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement.
Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu?
I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables, load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point). This could introduce another interface (fw_cfg+something rather than just fw_cfg), but ACPI table preparation would be concentrated in one project.
I guess.
Laszlo
On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek lersek@redhat.com wrote:
On 05/30/13 18:20, Jordan Justen wrote:
I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu.
I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement.
Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu?
I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables, load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point). This could introduce another interface (fw_cfg+something rather than just fw_cfg), but ACPI table preparation would be concentrated in one project.
I guess.
For reference, I believe that both Xen and virtualbox build ACPI table in the VMM rather than firmware. They both dump the tables into the 0xe000 segment (yuck) where firmware finds and publishes it to the OS. I think fw-cfg would be a reasonable alternative to this for communicating the tables.
-Jordan
Hi,
I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables,
Yes.
load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that),
The coreboot rom has named sections (this is called cbfs which stands for coreboot filesystem IIRC):
rincewind kraxel ~# cbfstool /usr/share/coreboot.git/bios.bin print bios.bin: 256 kB, bootblocksize 848, romsize 262144, offset 0x0 alignment: 64 bytes
Name Offset Type Size cmos_layout.bin 0x0 cmos_layout 1160 fallback/romstage 0x4c0 stage 14419 fallback/coreboot_ram 0x3d80 stage 37333 config 0xcfc0 raw 2493 fallback/payload 0xd9c0 payload 56969 vgabios/sgabios 0x1b8c0 raw 4096 (empty) 0x1c900 null 144216
where "fallback/payload" is seabios.
and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point).
As far I know coreboot can add more stuff such as acpi tables to cbfs at runtime and seabios able to access cbfs too and pull informations from coreboot that way.
HTH, Gerd
Gerd Hoffmann wrote:
and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point).
As far I know coreboot can add more stuff such as acpi tables to cbfs at runtime and seabios able to access cbfs too and pull informations from coreboot that way.
Only a minor correction - cbfs is the flash image, which so far doesn't really change at runtime. Stuff added at runtime goes into "coreboot tables" which is a coreboot-specified data structure which SeaBIOS finds and uses to know things like the memory map.
When using coreboot+SeaBIOS on real hardware, ACPI tables are built and put in place by coreboot, and never modified by SeaBIOS AFAIK.
//Peter
On Fri, May 31, 2013 at 2:32 AM, Gerd Hoffmann kraxel@redhat.com wrote:
Hi,
I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables,
Yes.
So, this is really about making coreboot+seabios the default QEMU firmware, and making seabios depend on being a coreboot payload?
load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that),
It wouldn't be loading OVMF. It would be loading CorebootPkg.
OVMF is a better sample platform for EDK II since it shows a more realistic view of what an EDK II based platform looks like on real hardware.
Thus, if the ACPI tables are just being added to a new coreboot layer with coreboot becoming the default QEMU firmware, then it doesn't help OVMF (or other non-coreboot payloads).
Well, it could if the table code was BSD licensed, but only so we could then merge them into OVMF. Then again, why not just provide a set of suitably licensed ACPI source files within the QEMU tree that firmware projects could use? QEMU doesn't necessarily need to build/link them, or attempt to communicate them at runtime.
-Jordan
The coreboot rom has named sections (this is called cbfs which stands for coreboot filesystem IIRC):
rincewind kraxel ~# cbfstool /usr/share/coreboot.git/bios.bin print bios.bin: 256 kB, bootblocksize 848, romsize 262144, offset 0x0 alignment: 64 bytes
Name Offset Type Size cmos_layout.bin 0x0 cmos_layout 1160 fallback/romstage 0x4c0 stage 14419 fallback/coreboot_ram 0x3d80 stage 37333 config 0xcfc0 raw 2493 fallback/payload 0xd9c0 payload 56969 vgabios/sgabios 0x1b8c0 raw 4096 (empty) 0x1c900 null 144216
where "fallback/payload" is seabios.
and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point).
As far I know coreboot can add more stuff such as acpi tables to cbfs at runtime and seabios able to access cbfs too and pull informations from coreboot that way.
HTH, Gerd
-
Gerd Hoffmann -
Jordan Justen -
Laszlo Ersek -
Peter Stuge