[SeaBIOS] [PATCH] smbios: Allow all fields to be set via qemu_cfg_smbios_load_field()

Alex Williamson alex.williamson at redhat.com
Tue Jun 22 06:29:06 CEST 2010


On Tue, 2010-06-22 at 00:03 -0400, Kevin O'Connor wrote:
> On Mon, Jun 21, 2010 at 09:32:36PM -0600, Alex Williamson wrote:
> > On Mon, 2010-06-21 at 23:06 -0400, Kevin O'Connor wrote:
> > > On Mon, Jun 21, 2010 at 09:46:19AM -0600, Alex Williamson wrote:
> > > > The protocol we use between qemu and seabios already allows any field
> > > > to be specified (via smbios_add_field() in qemu).  This patch makes
> > > > seabios look for qemu specified values for nearly every field we set
> > > > in the types 0,1,3,4,16,17,32 smbios tables.  No change in current
> > > > default values for any fields.
> > > 
> > > What's the use case for this?
> > > 
> > > Also, I feel obligated to ask the question - if we want qemu to be
> > > able to override any smbios field, wouldn't it be simpler to just have
> > > qemu pass the smbios table?
> > 
> > We can already do nearly all of type 0 & 1 fields.  We were looking at
> > setting some of the type 3 and 4 fields, like the manufacturer strings.
> > Rather than add support for a field here, another there, I thought I
> > might as well add support for everything I can since the infrastructure
> > to change them from qemu is already in place.  At some point it might
> > make sense to move all of the smbios generating code into qemu, but it's
> > mighty convenient for now to just be able to poke in specific fields.
> > Distros might want to do this for consistency or customization.
> > Developers might use this for being able to create a system with
> > arbitrary DMI changes (ex. did my system boot from the power switch,
> > modem ring, or a/c cycle).  Thanks,
> 
> Thanks.  Do you know if we're likely to see additional types (ie,
> something other than 0,1,3,4,16,17,32)?

We already supply a pretty good set of the basic types.  I won't rule
out adding new ones, but it doesn't seem likely.  If someone wants to
add another for a special case, we do support loading arbitrary tables
as a complete chunk via the same interface.  Commit b6f6e3d3 in the qemu
tree describes how to extract a table from a physical system and add it
to a qemu VM.

I will note that type 16 & 17 fields are somewhat partial coverage
because I don't allow overriding the memory size and layout.  This seems
like a step beyond picking a different type from an enum or replacing a
string.  Likewise, we supply type 19 & 20 tables, but these are entirely
based on memory layout, so I'm not sure it makes sense to allow field
setting.  The table load option is still available should someone want
to poke these.  Thanks,

Alex




More information about the SeaBIOS mailing list