Re: [Qemu-devel] Moving BIOS tables from SeaBIOS to QEMU

[Gleb Natapov]

On Sun, Feb 24, 2013 at 01:00:28PM -0500, Kevin O'Connor wrote:
> On Sat, Feb 23, 2013 at 04:47:26PM +0000, David Woodhouse wrote:
> > On Sat, 2013-02-23 at 11:38 -0500, Kevin O'Connor wrote:
> > > IMO, we need to move the ACPI table creation (and PIR/MPTABLE/SMBIOS)
> > > to QEMU and just have QEMU pass the tables to SeaBIOS for it to copy
> > > into memory like it does on CSM, coreboot, and Xen.
> > 
> > I believe it's on Laszlo's TODO list.
> 
> Laszlo, what is your plan for doing this?
> 
> I did a review of the SeaBIOS code to see what information is
> currently used to generate the ACPI, SMBIOS, MPTABLE, and PIR bios
> tables.  Here's what I came up with:
> 
> - hardcoded information: Most of the tables are simply hardcoded with
>   various values.  This should not be a problem to move to QEMU
> 
IIRC SMBIOS has some tables with information about a BIOS.

> - information passed in from QEMU: RamSize, RamSizeOver4G, fw_cfg
>   (irq0-override, system suspend states, numa memory, additional acpi
>   tables, smbios overrides).  These should also be possible to obtain
>   directly within QEMU (though I'm unsure how qemu exposes this
>   information internally).
> 
> - CPU information: Number of CPUs, the apic id of the CPUs, which CPUs
>   are active, and the cpuid information from the first CPU.  Again
>   this should be available in QEMU, but I'm not sure what the internal
>   interfaces look like for obtaining it.
> 
> - Various hardware probes: The ioapic version, whether or not hpet is
>   present, running on piix4 or ich9, whether or not acpi should be
>   used.  Again should be possible to obtain from QEMU with sufficient
>   interfaces.
> 
> - PCI device info: The list of PCI devices, PCI buses, pin
>   assignments, irq assignments, if hotplug supported, and memory
>   regions.  This should mostly be available in QEMU - order of
>   initializing would be important so that the tables were initialized
>   after all PCI devices.
> 
> Of these, the only thing I see that could be problematic is the PCI
> irq assignments (used in mptable) and the PCI region space (used in
> ACPI DSDT _SB.PCI.CRS).  These are slightly problematic as they
> currently rely somewhat on the current SeaBIOS pciinit.c bridge/device
> setup.  However, the mptable irqs is a simple algorithm that could be
> replicated in QEMU, and it looks to be of dubious value anyway (so
> could possibly be dropped from the mptable).  Also, the PCI region
> space does not need to be exact, so a heuristic that just ensured it
> was large enough should suffice.
> 
Again IIRC there are still OSes that uses mptable to obtain irq
information. See 928d4dffef5c374.

> Given this, one possible way to migrate the ACPI tables from SeaBIOS
> would be to:
> 
> 1 - replace the BDAT PCI range interface in SeaBIOS with a SSDT based
>     template system similar to the way software suspend states are
>     handled in SeaBIOS today.  This would eliminate the only runtime
>     references to SeaBIOS memory from ACPI.
> 
> 2 - relicense the SeaBIOS' acpi.c, mptable.c, pirtable.c, smbios.c
>     code to GPLv2 (from LGPLv3) and copy into QEMU.  Only I've claimed
>     a copyright since Fabrice's work (LGPLv2) and I'm willing to
>     relicense.  There have been a handful of contributors to these
>     files, but they all look to be regular QEMU contributors so I
>     don't think there would be any objections.  Along with the code,
>     the IASL parsing code and associated build python scripts would
>     also need to be copied into QEMU.
> 
> 3 - update the code to use the internal QEMU interfaces instead of the
>     SeaBIOS interfaces to obtain the information outlined above.
> 
> 4 - pass the tables from QEMU to SeaBIOS via the fw_cfg interface.
>     The PIR, MPTABLE, and SMBIOS are easy to copy into memory from
>     fw_cfg.  The ACPI does have a few tables that are special (RSDP,
>     RSDT, FADT, DSDT, FACS), but it should be easy to detect these and
>     update the pointers in SeaBIOS during the copy to memory.
> 
> Thoughts?
> 
> -Kevin

--
                        Gleb.