[SeaBIOS] [PATCH v2 9/9] seabios: Build the dsdt separately
kevin at koconnor.net
Thu Oct 11 03:22:13 CEST 2012
On Wed, Oct 10, 2012 at 09:05:11AM +0200, Gleb Natapov wrote:
> On Tue, Oct 09, 2012 at 08:04:12PM -0400, Kevin O'Connor wrote:
> > On Mon, Oct 08, 2012 at 11:35:15PM -0400, Jason Baron wrote:
> > > From: Jason Baron <jbaron at redhat.com>
> > >
> > > This builds seabios such that the dsdt tables are no longer built into the
> > > seabios binary. They must be passed to the seabios via fw_cfg. This saves
> > > space in the seabios binary for unnecessary dsdt tables.
> > >
> > > I suspect that this will make other users of Seabios, besides qemu unhappy,
> > > but I'm not sure.
> > Only qemu/kvm uses the acpi support in seabios. (If one excludes
> > bochs which hasn't really used seabios.) Coreboot and Xen both deploy
> > acpi completely separately from seabios.
> > Instead of moving just the dsdt to qemu, though, can we move all acpi
> > tables into qemu? Moving just the dsdt can lead to conflicts with the
> > generated ssdt code and potentially some of the other acpi tables.
> > The only seabios acpi dependency that pops into mind is the memory
> > addresses of the acpi tables themselves. It should be trivial to have
> > seabios create the rsdt/rsdp while pulling all the remaining acpi
> > tables from qemu via fw_cfg. Almost all the tables in acpi describe
> > hardware and not the firmware. Are there other cases where the
> > firmware needs to have input when generating the contents of an acpi
> > table?
> There is a BDAT OperationRegion that points to memory allocated by
All the info passed via BDAT is available in QEMU. Granted, a method
other than BDAT would be needed to pass the info, but that should not
More information about the SeaBIOS