So what I am now posting as an RFC started life as a patch series to introduce SMBIOS table pass-through for HVMs ([PATCH 0/3] SMBIOS table passthrough support). After getting feedback from the community (thank you) and giving it some thought I decided to try this approach and in the process expand the scope of the functionality that I am attempting to introduce. Overview: Pass-through of portions of a host''s firmware (specifically SMBIOS and ACPI) is useful in supporting vendor/OEM specific functionality in HVM guests. This includes OEM platform specific software and drivers, support for custom value add hardware like laptop buttons, device pass-through firmware requirements, etc. The proposal is to build a somewhat generic interface to pass in certain pieces of the platform BIOS for inclusion in the virtual firmware as built by HVMLOADER. The first section will cover the primary functionality of the proposal; this being the creation of a generic framework to pass platform firmware data to HVMLOADER during HVM guest creation. The second section will cover the possible inclusion of an HVM helper library to generate the firmware data format for HVMLOADER and tool-stack considerations. BIOS Pass-through Framework: The first part is to build a framework to load firmware "modules" with the HVMLOADER when creating a guest. The earlier idea was to use the shared HVM info page but this is being phased out. The current consensus seems to be that the modules can be loaded into the guest while it is built. Specifically they can be loaded in much the same way as HVMLOADER is by libxc and note these modules are only for use by the HVMLOADER. HVMLOADER is copied into what will become the RAM area in the E820 and the HVMLOADER modules could be stacked up behind it in that same area: 0000000000100000 - HVMLOADER 0000000000200000 - 1-N HVMLOADER MODULES These modules will effectively "disappear" with the HVMLOADER once control is given to the guest BIOS and E820 identifies that area as usable RAM. The HVMLOADER modules would have a standard layout defined in a public header. All modules would all have a standard header with the basics: signature, type, length, checksum, with this followed by a type specific header. At the moment there would be support for ACPI and SMBIOS table pass-through. The HVMLOADER will have to be modified to process the specific module types and load them in the appropriate manner. It is conceivable that this same mechanism could be used to load other types of firmware information e.g. for adding or overriding OROMs. The exact nature of how this functionality would be used is not really built into this proposal. This merely provides a mechanism to customize an HVM''s virtual firmware is a variety of ways. By default, the addition of this functionality will not change the current behavior in any way. How modules are generated and managed would vary by use case. For example, the question of guest launch measurement came up. This model would allow the HVMLOADER and associated modules to be measured by a domain builder but that would mean tight control over the creation and maintenance of the modules. Here are a few details that need to be thought out (and there are probably more than are listed): - The minimum HVM size is currently 2Mb - this would have to increase, perhaps derived off the total module(s) size. - ACPI builder uses some scratch space behind HVMLOADER to build the tables the first time - have to make sure this doesn''t crash into the modules. - Need suggestions on how to best modify libxc to do this work; it is fairly clear where it would happen but it probably needs a new API. - How to tell HVMLOADER where the module(s) base GPA is: register, xenstore, ? - Other firmware information like simple string/numeric values and meta information like control flags can be passed in xenstore. Library and Tool-stack Support: In addition to the HVMLOADER support, it would be helpful to have a library that would read the relevant platform information and write the HVMLOADER modules in the proper format. This library could be extended to help manage the various xenstore keys that are used in HVMLOADER but not really defined a particular location. And yet one step further, this library could be used to setup the current values that passed via the HVM info table allowing us to deprecate the latter''s use. For the moment changes to the open source tool-stacks is not being considered beyond changes to libxc to support the loading of modules. This is obviously up for discussion too. Thanks and sorry for the lengthiness... Ross Philipson Senior Software Engineer Citrix Systems, Inc 14 Crosby Drive Bedford, MA 01730 781-301-7949 ross.philipson@citrix.com