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: Gabriel L. Somlo
Subject: Re: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)
Date: Fri, 4 Apr 2014 21:15:14 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Apr 04, 2014 at 08:34:11PM -0400, Kevin O'Connor wrote:
> > 
> > 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.)

I like this idea too: older/current versions of qemu just do what they
do, and work with SeaBIOS the way they always have. Future versions
just send a completely new fw_cfg message type, which, when
encountered by SeaBIOS, causes it to only add in (or edit) type 0, and
leave everything else as is.

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

The only fly in this ointment may be that type 0 doesn't have a fixed
length that could be edited in place, if you consider the various
strings that get tacked on to the end of it. So you'd still have to
slide the rest of the smbios payload left or right to shrink or
enlarge the type 0 blob, depending on how you modify the various
strings it contains...

--Gabriel



reply via email to

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