[SeaBIOS] [PATCH 0/9] q35 seabios support take #1

Jason Baron jbaron at redhat.com
Fri Sep 14 16:35:49 CEST 2012

On Fri, Sep 14, 2012 at 09:23:46AM +0200, Paolo Bonzini wrote:
> Il 13/09/2012 22:12, Jason Baron ha scritto:
> > Subject: [PATCH 0/9] q35 seabios support take #1
> > 
> > Hi,
> > 
> > Seabios bits for q35 support, I'm posting the qemu changes separately. The
> > patches require '-M pc_q35' and -L 'seabios dir with q35 changes' on the
> > qemu command line. Hopefully, we can make it the default for x86 at some future
> > point when we feel comfortable with it.
> The main question, IMHO, is how to proceed for supporting both PIIX4 and
> q35.  The two extreme possibilities are:
> - use a single binary for everything
> - use two binaries for everything
> Right now, you do a mix of the two, where you have two DSDTs and one
> binary.  Furthermore, PIIX4 is still a "preferred" chipset in that its
> DSDT is embedded in SeaBIOS and q35's isn't.
> With more than one chipset being supported, and with the desire to
> support OVMF/UEFI as an alternative firmware, I think it makes sense to
> move QEMU towards a model more similar to CoreBoot's, where QEMU itself
> makes the default ACPI tables and passes them to SeaBIOS or OVMF via fw_cfg.
> So my favorite choice is to move the DSDT to fw_cfg, and keep a single
> binary for everything else.  I don't really care whether the DSDT
> sources live in the SeaBIOS or QEMU repository, though the former makes
> more sense until all things ACPI are done in QEMU.

Yes agreed, especially since I needlessly wasting ram on q35 with the
piix acpi table.

In terms of implementation then, qemu would basically advertise a single
dsdt table (based on the -M) using fw_cfg, and then seabios would pick
up the correct one. Is that the right way to think about it?



More information about the SeaBIOS mailing list