qemu-devel
[Top][All Lists]
Advanced

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

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


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
Date: Fri, 31 May 2013 12:05:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130513 Thunderbird/17.0.6

On 05/31/13 10:13, Peter Stuge wrote:
> Kevin O'Connor wrote:
>> one possible way forward would be to split the current SeaBIOS rom
>> into two roms: "qvmloader" and "seabios".  The "qvmloader" would do
>> the qemu specific platform init (pci init, smm init, mtrr init, bios
>> tables) and then load and run the regular seabios rom.
> 
> qvmloader sounds a lot like coreboot.

Indeed.

> ACPI bytes are obviously a function of QEMU configuration. QEMU
> configuration can be changed through a great many channels, so it
> makes sense to me that QEMU itself would take care of generating
> correct ACPI, rather than exporting it's own data structures and
> pushing the ACPI problem onto the firmware, especially considering
> the desire for multiple independent firmware implementations.

Can't agree more.

I still think the best solution is to have qemu generate the acpi tables
and all firmware can just grab them.

Second best option would be to have coreboot generate them and
everything else go on top of coreboot then.

Third best option is to duplicate the acpi generation code in all
firmware variants (this is what we have today).

IMO qvmloader would be even worse than these three.  Writing a piece of
firmware is alot more tricky than a linux userspace app, especially in
x86 land with the funky mode switching and assembler modes.

cheers,
  Gerd





reply via email to

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