qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]