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

From: Anthony Liguori <aliguori@us.ibm.com>
To: Alex Williamson <alex.williamson@hp.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, kvm <kvm@vger.kernel.org>
Subject: Re: [PATCH 1/2] qemu: Allow SMBIOS entries to be loaded and provided to the VM BIOS
Date: Mon, 06 Apr 2009 17:42:19 -0500	[thread overview]
Message-ID: <49DA854B.4000905@us.ibm.com> (raw)
In-Reply-To: <1239057273.4726.76.camel@lappy>

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