[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Moving BIOS tables from SeaBIOS to QEMU
From: |
Kevin O'Connor |
Subject: |
[Qemu-devel] Moving BIOS tables from SeaBIOS to QEMU |
Date: |
Sun, 24 Feb 2013 13:00:28 -0500 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- 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.
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
- [Qemu-devel] Moving BIOS tables from SeaBIOS to QEMU,
Kevin O'Connor <=