[PATCH 1/3] SMBIOS table passthrough support

[PATCH 1/3] SMBIOS table passthrough support

[Ross Philipson]

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

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.

Signed-off-by: Ross Philipson <ross.philipson@citrix.com>



[-- Attachment #2: smbios-passthrough-01.patch --]
[-- Type: application/octet-stream, Size: 1882 bytes --]

diff -r 0900b1c905f1 xen/include/public/hvm/hvm_info_table.h
--- a/xen/include/public/hvm/hvm_info_table.h	Mon Feb 20 18:58:07 2012 +0000
+++ b/xen/include/public/hvm/hvm_info_table.h	Mon Feb 20 20:35:36 2012 -0500
@@ -25,12 +25,15 @@
 #ifndef __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__
 #define __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__
 
-#define HVM_INFO_PFN         0x09F
-#define HVM_INFO_OFFSET      0x800
-#define HVM_INFO_PADDR       ((HVM_INFO_PFN << 12) + HVM_INFO_OFFSET)
+#define HVM_INFO_PFN           0x09F
+#define HVM_INFO_OFFSET        0x800
+#define HVM_INFO_PADDR         ((HVM_INFO_PFN << 12) + HVM_INFO_OFFSET)
+#define HVM_SMBIOS_INFO_OFFSET 0x0
+#define HVM_SMBIOS_INFO_PADDR  ((HVM_INFO_PFN << 12) + HVM_SMBIOS_INFO_OFFSET)
+#define HVM_SMBIOS_INFO_MAX    0x800
 
 /* Maximum we can support with current vLAPIC ID mapping. */
-#define HVM_MAX_VCPUS        128
+#define HVM_MAX_VCPUS          128
 
 struct hvm_info_table {
     char        signature[8]; /* "HVM INFO" */
@@ -69,4 +72,31 @@
     uint8_t     vcpu_online[(HVM_MAX_VCPUS + 7)/8];
 };
 
+struct hvm_smbios_table_header {
+    /*
+     * Beginning after this stucture, includes fixed table size 
+     * string list, and terminator.
+     */
+    uint32_t    length;
+};
+
+#define HVM_SMBIOS_INCLUDE_SYSTEM_BOARD     0x00000001
+#define HVM_SMBIOS_INCLUDE_PORTABLE_BATTERY 0x00000002
+#define HVM_SMBIOS_INCLUDE_POWER_SUPPLY     0x00000004
+#define HVM_SMBIOS_INCLUDE_VENDOR_OEM       0x00000008
+
+struct hvm_smbios_info_table {
+    char        signature[8]; /* "SMBIOSPT" */
+    uint32_t    length; /* all tables + this struct */
+    uint8_t     checksum;
+
+    /* Control flags for table options */
+    uint32_t    flags;
+
+    /* Count of table headers that following this stucture. */
+    uint32_t    count;
+
+    /* Begin SMBIOS tables */
+};
+
 #endif /* __XEN_PUBLIC_HVM_HVM_INFO_TABLE_H__ */

[-- Attachment #3: Type: text/plain, Size: 132 bytes --]

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

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

[Ian Campbell]

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.

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

[Ross Philipson]

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Tuesday, February 21, 2012 3:47 AM
> To: Ross Philipson
> Cc: xen-devel@lists.xensource.com
> 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 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.

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.

Anyway, any thoughts or suggestions are most welcome, thanks.

Ross

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

[Ian Campbell]

On Tue, 2012-02-21 at 13:42 +0000, Ross Philipson wrote:
> > -----Original Message-----
> > From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> > Sent: Tuesday, February 21, 2012 3:47 AM
> > To: Ross Philipson
> > Cc: xen-devel@lists.xensource.com
> > 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.

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

[Cihula, Joseph]

> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel-bounces@lists.xen.org] 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@citrix.com]
> > > Sent: Tuesday, February 21, 2012 3:47 AM
> > > To: Ross Philipson
> > > Cc: xen-devel@lists.xensource.com
> > > 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

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

[Ross Philipson]

> -----Original Message-----
> From: Cihula, Joseph [mailto:joseph.cihula@intel.com]
> Sent: Tuesday, February 21, 2012 3:35 PM
> To: Ian Campbell; Ross Philipson
> Cc: xen-devel@lists.xensource.com
> Subject: RE: [Xen-devel] [PATCH 1/3] SMBIOS table passthrough support
> 
> > From: xen-devel-bounces@lists.xen.org
> > [mailto:xen-devel-bounces@lists.xen.org] 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@citrix.com]
> > > > Sent: Tuesday, February 21, 2012 3:47 AM
> > > > To: Ross Philipson
> > > > Cc: xen-devel@lists.xensource.com
> > > > 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

Joe, thanks for the feedback. From the other comments I have received, I believe I will use an approach where bits of virtual firmware like passed in SMBIOS tables (or other pieces I am working on like ACPI SSDTs that are passed in at runtime) will be loaded into the new guest as a set of modules. These modules will solely be for consumption by hvmloader. In light of this, I believe the latter of the two scenarios you mentioned will be the case; that a domain builder measures the initial building blocks like hvmloader any associated modules.

The area I am still considering though is dealing with platform firmware updates and how they would be reflected in a given set of hvmloader modules where obviously changing those modules would mean a different measurement. More broadly, I guess I don't know enough about how changes to platform firmware is handled with respect of platform measurements (and it seems to me the case of the guest and vTPMs is just an extension of this)?

Ross

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

[Tim Deegan]

> > 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?

That seems better than passing it through the hypervisor. :)  If the
builder is already loading them into RAM we could just stick a linked
list at a know address rather than go through Xenstore - at least for
things that aren't needed by anything except hvmloader.

Tim.