[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28

From: Jordan Justen
Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
Date: Thu, 30 May 2013 09:57:10 -0700

On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]