On 05/30/13 18:57, Jordan Justen wrote:
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.
I think Xen uses a separate utility called "hvmloader" that runs in the domU.
- http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5453/focus=5668 - http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=tools/firmware/hvmloader - http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/6255/focus=110562
Laszlo
-
Laszlo Ersek