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.
