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 <[email protected]> > > > > > > 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 > Seabios.
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 be difficult. -Kevin _______________________________________________ SeaBIOS mailing list [email protected] http://www.seabios.org/mailman/listinfo/seabios
