Re: [PATCH 1/2] qemu: Allow SMBIOS entries to be loaded and provided to the VM BIOS

Anthony Liguori
2009-04-06T22:42:23Z

Alex Williamson wrote:
> Hi Anthony,
>
> On Mon, 2009-04-06 at 14:50 -0500, Anthony Liguori wrote:
>
>> Alex Williamson wrote:
>>
>> I know we have to support blobs because of OEM specific smbios entries,
>> but there are a number of common ones that it would probably be good to
>> specify in a less user-unfriendly way. What do you think?
>>
>
> Yeah, I'll admit this is a pretty unfriendly interface. I get from your
> comment on the other part of the patch that you'd prefer not to get into
> the mess of having both binary blobs and command line switches
> augmenting the blobs. This seems reasonable, but also means that we
> need a way to fully define the tables we generate from the command line.
> For a type 0 entry, that might mean the following set of switches:
>
> -bios-version, -bios-date, -bios-characteristics, -bios-release
>

You could go one level higher:

-smbios type=0,bios-version='1.0',bios-date='2009/10/20' etc.

> I'm sure I'm missing some, plus we might want to allow the memory and
> processor entries to have some fields changed. Do we want to add that
> many switches and means to access them from the rombios?
>

I think it's okay to start with some of the more common tables and
provide the parsing in QEMU. We could then introduce humanize more
tables down the road as people saw fit.

At the end of the day, I'm most interested in the tables that are going
to be frequently used by management applications. That is, the tables
that are required for things like SVVP certification should be specified
in a human readable format that QEMU can build reasonable defaults for
and management tools can override.

I'm torn between exposing the tables directly to the firmware or
providing a higher level interface. I really don't like -uuid
overriding a binary blob though so I'd prefer to avoid that. -uuid
should only be respected if using the QEMU generated version of the
SMBIOS table. I'll defer to whatever you think is better what is
exposed in the firmware interface as I can see arguments for both.

--
Regards,

Anthony Liguori