qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in


From: Kevin O'Connor
Subject: Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)
Date: Fri, 4 Apr 2014 20:34:11 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Apr 02, 2014 at 05:04:57PM +0200, Gerd Hoffmann wrote:
> > >   - therefore, the maximum granularity of QEMU-generated
> > >     elements should be full tables of a given type, and
> > >     not the full SMBIOS blob at once (other mechanisms to
> > >     allow the BIOS to insert its own type 0 welcome, but
> > >     so far this seems the most straightforward one).
> 
> Just an idea:  Is the table ordering important?  I don't think so.  If
> qemu supplies a blob with all tables except type0, can the firmware
> simply append a type0 record to the blob supplied by qemu?

I don't see anything in the spec that would prohibit it, but I don't
think it's done in practice.  Given how many different OS parsers
there are and their dubious quality, I think we'd want to be as simple
as possible and continue to put table 0 at the start.

> > I don't agree - I think ultimately we want QEMU to generate the full
> > SMBIOS table and pass it to the firmware via the romfile_loader
> > mechanism.
> 
> I still think the firmware (and *only* the firmware) should supply the
> type0 table.  I also think seabios should fill in something more
> sensible in there, such as "Vendor: SeaBIOS" and "Version:
> rel-1.7.4-0-g96917a8-...".
> 
> > The only thing that has been raised as an issue with this
> > is one bit in the smbios table (UEFI support).
> 
> IMO 'dmidecode -t0' should show what firmware you are running
> (seabios/ovmf/coreboot/whatever), not something made up by qemu.

Ultimately my preference would be to make a clean break from the
existing smbios fw_cfg system as it is too complex, too confusing, and
too inflexible.  We could implement the above as you suggest, but I
fear it would require keeping much of the complexity of the current
fw_cfg interface.  (It's also a new feature as SeaBIOS doesn't
currently put any useful info in type 0.)

The already existing romfile_loader interface seems to provide a
nearly complete solution to replace the smbios fw_cfg system.  If
there is really demand for more firmware info in the type 0 table, why
don't we use romfile_loader, have qemu put together a dummy type 0
table, and then have seabios update it in place?  Sure, that's ugly,
but I'm pretty sure it would be less ugly then keeping the existing
smbios fw_cfg system around.

-Kevin



reply via email to

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