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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-04-11 at 17:29 +0100, Ross Philipson wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: Wednesday, April 11, 2012 4:45 AM
> > To: Ross Philipson
> > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> > 
> > On Tue, 2012-04-10 at 20:04 +0100, Ross Philipson wrote:
> > > 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, to use the terminology of tools/firmware/hvmloader/smbios_types.h,
> > you have entities which are subsets of a structure and so do not start
> > with a "struct smbios_structure_header"?
> > 
> > Ian.
> > 
> 
> Yea so the entire SMBIOS table begins with the "struct
> smbios_entry_point" which is not present in what I pass in. I have N
> structs (possibly some of the same type) that start with a "struct
> smbios_structure_header". The gotcha is that the "length" field only
> defines the fixed portion of each of the SMBIOS structs. There can be
> any number of strings following that struct of varying length.

Ah, that's the bit I had forgotten...

>  Then entire structure is doubly terminated with "\0\0". What I wanted
> to avoid is having to put the parsing code in hvmloader to reparse for
> each struct, which was already done by the tools. A simple approach is
> to use the <length><blob> scheme.

Yes, I see now why this is necessary, thanks for plugging away at my
understanding ;-)

Ian.



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