Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support

["Cihula, Joseph" <joseph.cihula@xxxxxxxxx>]

> From: xen-devel-bounces@xxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxx] On Behalf Of Ian
> Campbell
> Sent: Tuesday, February 21, 2012 7:21 AM
> 
> On Tue, 2012-02-21 at 13:42 +0000, Ross Philipson wrote:
> > > -----Original Message-----
> > > From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> > > Sent: Tuesday, February 21, 2012 3:47 AM
> > > To: Ross Philipson
> > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
> > > Subject: Re: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough
> > > support
> > >
> > > On Tue, 2012-02-21 at 02:56 +0000, Ross Philipson wrote:
> > > > Updates to the layout of the HVM parameter and information page
> > > > defined in hvm_info_table.h. The SMBIOS pass-through tables are
> > > > written to the bottom half of this page.
> > >
> > > We would like to eventually get rid of the HVM info page and would
> > > certainly like to avoid adding anything further there. Could this
> > > data not be supplied via xenstore? Certainly they could and should
> > > be for the ones controlled by the flags entry which you add.
> > >
> > > Ian.
> > >
> >
> > Ah I did not realize that. The original incarnation of this code came
> > from 2+ years ago. I have no objection to using xenstore but I did not
> > think xenstore was suitable for passing arbitrary blocks of binary
> > data (i.e. the raw SMBIOS firmware tables). Perhaps I am incorrect in
> > this assumption.
> 
> I think in principal binary data is supported, but its use is discouraged. 
> docs/misc/xenstore.txt
> talks about it a bit.
> 
> For well defined entries it should be reasonable to have human readable 
> content in xenstore which
> simply enable/disables the table and perhaps contains some configuration 
> values as appropriate.
> 
> For adding arbitrary tables I'm less sure what the right answer is.
> Common header elements in human readable form, payload as hex encoded strings 
> or something? Seems
> a bit icky though.
> 
> > I am not sure what other mechanisms could be employed. In other code I
> > use in out hvmloader, I pass an ACPI SSDT to the hvmloader at runtime.
> > I use a little DMAish interface I built into qemu to push the SSDT to
> > hvmloader while it is building the ACPI tables. Something like this
> > could be used but I don't really want to get qemu involved in this
> > operation.
> 
> Yes, I think we should avoid that too.
> 
> > I guess a third option might be to have a facility to load extra
> > modules/files into the new domain at start time and specify their
> > gpa's in xenstore. They could then be discarded after the initial
> > domain setup is complete.
> 
> That might work. What do others around here think?
> 
> Ian.

In deciding which approach to use, you should keep in mind that eventually it 
will be desirable to measure the VM (i.e. into a virtual TPM).  So if the data 
is going to be processed by code that is TPM-aware, then any approach to 
getting it the data should allow for measurement.  But if the processing code 
is not TPM-aware and is measured by the domain builder code, then the data 
should be provided in a way that the domain builder can easily measure it.

Joe

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