Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell
> Sent: Tuesday, April 10, 2012 11:39 AM
> To: Ross Philipson
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Tim (Xen.org)
> Subject: RE: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> On Tue, 2012-04-10 at 16:28 +0100, Ross Philipson wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: Tuesday, April 10, 2012 10:22 AM
> > > To: Ross Philipson
> > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> > > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > >
> > > On Thu, 2012-04-05 at 21:06 +0100, Ross Philipson wrote:
> > > > > I see. So you need to be able to find the individual tables so
> > > > > that smbios_type_<N>_init can check for an overriding table <N>
> > > > > in the passed-through tables, it seems reasonable to try and
> > > > > avoid needing to parse a big lump of tables each time to see if
> > > > > the one you are interested in is there.
> > > > >
> > > > > I think this can work by having .../smbios/<N>/{address,etc} in
> > > > > XenStore. You could also have .../smbios/OEM/{...} for the stuff
> > > > > for smbios_type_vendor_oem_init, which I think could easily just
> > > > > be a single lump?
> > > > >
> > > > > I think you don't need the same thing for the ACPI side since
> > > > > there you just provide secondary tables?
> > > >
> > > > There could be quite a few SMBIOS tables being passed in. On the
> > > > order of 20 - 30 of them and thet are pretty small. It seems a bit
> > > > odd to break it up like this for lots of little chunks. There
> > > > could be more than one ACPI table also (multiple SSDTs and/or
> other static tables).
> > > > Also the OEM SMBIOS tables are all discrete and they could not go
> > > > in as a single lump.
> > >
> > > I'm not sure if there are arguments here both for and against having
> > > a single smbios blob vs multiple?
> >
> > Oh sorry. I am trying to answer 2 different things here. In summary
> > what I would like to do is not make any distinction between vendor and
> > predefined tables but rather send all SMBIOS tables in as a single
> > lump with some sort of internal delimiter structs. If that is
> > unacceptable then all the SMBIOS tables would be put in xenstore per
> > what you said above (.../smbios/<N>/{address,etc}). It just seems odd
> > to me to break up the (usually rather small and potentially numerous)
> > SMBIOS tables into individual items passed in xenstore.
> 
> What sort of delimiter were you thinking of? Perhaps something as simple
> as:
>       <length><blob><length><blob>

Yea, that would suffice.

> ?
> 
> Or can you use the length field in the smbios entry header?
> 
> Ian.
> 

Not really. I think part of the problem here is my mixing of terminology. For 
SMBIOS bits I am pulling apart the overall SMBIOS table and just grabbing a 
desired subset of the SMBIOS structures. The individual structures are the 
entities that do not have an overall length field so I want to stick them back 
together as one lump with a length delimiter - what you described above is 
perfectly sufficient.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel