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> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xensource.com/xen-devel
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.
> -----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
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.
> 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
> > 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.
> -----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. > > JoeJoe, 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