[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Kevin O'Connor
Subject: Re: [Qemu-devel] Moving BIOS tables from SeaBIOS to QEMU
Date: Mon, 25 Feb 2013 20:33:59 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Feb 25, 2013 at 10:51:55AM +0200, Gleb Natapov wrote:
> On Sun, Feb 24, 2013 at 01:00:28PM -0500, Kevin O'Connor wrote:
> > 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.

Most of the fields in these tables describe hardware, but you are
correct that a few fields describe the firmware.  After a quick review
on the SeaBIOS code, I came up with 3 firmware fields populated today:
SMBIOS type 1 bios_starting_address_segment, and ACPI FADT
acpi_enable/acpi_disable fields.  The bios_starting_address_segment is
given a bogus value (0xe800) today and I think we can continue to do
that.  (There are a couple of other firmware specific fields in the
SMBIOS type 1 struct (bios_characteristics), but they aren't populated
today anyway.)  For the SMI acpi_enable/disable fields we can update
the SMI handler to use the values found in the ACPI tables.  (Indeed,
the q35 support is already broken here because it declares values that
are different from what the SMI handler is expecting.)

> > 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.

Well, it shouldn't be needed for buses other than the root bus.
(Today, SeaBIOS will add an mptable entry for every PCI-PCI bridge,
and I don't think that is correct or useful.)  The other info isn't
too painful to put in QEMU - we just need the default PIN# -> IRQ
mapping, which can be described with "const u8 pci_irqs[4] = { 10, 10,
11, 11 };".


reply via email to

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