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