[Xen-devel] [RFC] HVM BIOS pass-through

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

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@xxxxxxxxxx



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