[SeaBIOS] Moving BIOS tables from SeaBIOS to QEMU

[Kevin O'Connor]

On Wed, Feb 27, 2013 at 03:09:25PM +0100, Laszlo Ersek wrote:
> On 02/27/13 10:19, Gerd Hoffmann wrote:
> > On 02/26/13 19:30, Laszlo Ersek wrote:
> >> On 02/26/13 10:03, Gerd Hoffmann wrote:
> >>
> >>> Can tianocore grab acpi tables from coreboot?
> >>
> >> Not that I know of. (... It may have been a rhetorical question.)
> > 
> > Wasn't rhetorical.  Generating the apci tables in both ovmf and seabios
> > doesn't make that much sense, better would be to have that in one place.
> > 
> > Option one is to let qemu provide them, then both ovmf and seabios can
> > grab them via fw_cfg.
> > 
> > Option two is to use coreboot underneath, then let both seabios and ovmf
> > grab the tables from coreboot.  Which of course requires that ovmf can
> > use the tables provided by coreboot.  Seabios can do that today.
> > 
> > /me looked around a bit in the coreboot source code.  Looks like they
> > simply copyed over the dsdt from seabios as-is, which doesn't fly due to
> > the pci _crs method referencing ssdt's BDAT.
> > 
> > From the quick look it seems they do *not* generate the dsdt
> > dynamically, only the other tables (simliar to seabios).  So switching
> > to coreboot probably doesn't help to remove the dsdt patching code we
> > have in seabios.
> > 
> >> When running on Xen, an area is searched for the RSDP, and linked tables
> >> (prepared by Xen's hvmloader I think) are installed by OVMF.
> > 
> > Ok, so doing something simliar when running on coreboot should be
> > possible without major headache.
> > 
> >> When running on qemu, static tables are used. I strived to adapt them as
> >> much as I could to qemu hardware. Some tables (recognized by header) are
> >> copied & modified dynamically before installation: MADT, SSDT.
> > 
> >> Getting a precise picture of qemu hardware in the form of ACPI tables
> >> (over fw_cfg) would not only allow OVMF to pass on better tables to
> >> OSPM; OVMF could *maybe* use them itself.
> > 
> > qemu 1.4+ places the dsdt into fw_cfg.  But again, that is the one which
> > references BDAT, so using it as-is in ovmf isn't going to fly ...
> 
> As far as I understood Kevin suggested to
> - remove the BDAT (FWDT in OVMF) and the related DSDT logic,
> - prepare the byte-code of the CRS dynamically from a template (t could
> be a Name instead of a Method) and patch the ranges before installation.

My suggestion was to replace BDAT with a dynamically generated P0S
(and P[01][SLE][LH]?) in an SSDT (by updating ssdt-sups.dsl).

-Kevin