On 05/30/13 18:57, Jordan Justen wrote: > On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek <lersek@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
