Re: [kvm] Re: [PATCH 1/2] qemu: Allow SMBIOS entries to be loaded and provided to the VM BIOS
On Mon, 2009-04-06 at 17:42 -0500, Anthony Liguori wrote:
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.
That helps, but we have the same complexity in getting the data into the
the bios. Adding a new QEMU_CFG_* for each field in every table we want
to specify seems excessive. I'm half tempted to generate all the smbios
entries in qemu and push them through a port to the bios. That would
leave a lot of duplicate code in bochs though. Maybe the bios could
read a stream of these through the port:
uint16_t length;
uint8_t type; /* 0: field, 1: table */
union {
struct {
uint8_t type; /* smbios entry type */
uint8_t offset;
uint8_t data[];
} field;
struct {
uint8_t data[]; /* binary blob */
} table;
} entry;
We could convert uuid to use this too. The bios doesn't have a very
effective means to seek through these, but maybe its not an issue as
long as these entries are sparsely used. We could also use the table
generation to enforce mutual exclusion between specifying fields and
tables to avoid the uuid issue in the previous set. Other ideas?
Thanks,
Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] Re: [PATCH 1/2] qemu: Allow SMBIOS entries to be loaded and provided to the VM BIOS
Alex Williamson wrote:
On Mon, 2009-04-06 at 17:42 -0500, Anthony Liguori wrote:
That helps, but we have the same complexity in getting the data into the
the bios. Adding a new QEMU_CFG_* for each field in every table we want
to specify seems excessive.
Right.
I'm half tempted to generate all the smbios
entries in qemu and push them through a port to the bios. That would
leave a lot of duplicate code in bochs though. Maybe the bios could
read a stream of these through the port:
uint16_t length;
uint8_t type; /* 0: field, 1: table */
union {
struct {
uint8_t type; /* smbios entry type */
uint8_t offset;
uint8_t data[];
} field;
struct {
uint8_t data[]; /* binary blob */
} table;
} entry;
We could convert uuid to use this too.
Yes, this is what I was leaning toward too.
The bios doesn't have a very
effective means to seek through these, but maybe its not an issue as
long as these entries are sparsely used. We could also use the table
generation to enforce mutual exclusion between specifying fields and
tables to avoid the uuid issue in the previous set. Other ideas?
I'm pretty happy with this. The argument against it is that if we pass
higher level information down via the FW interface, other types of FW
(like OpenBIOS) could also use that information in a meaningful way.
The problem is, beyond things like UUID, you start to get into pretty
specific stuff and I'm not convinced it would all generalize very well.
OEM tables are also impossible to represent this way.
So yeah, plumbing the tables directly through to the BIOS seems to make
sense to me.
Thanks,
Alex
--
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
