Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough

[Ross Philipson <Ross.Philipson@xxxxxxxxxx>]

Well I am keen to hear what other have to say but here are some of my thoughts. 
I built the framework to be really generic so you could pass just about 
anything in using these modules. It doesn't really rely on xenstore at all but 
I guess I was under the impression that that is how folks wanted simple 
information to be passed to a nascent guest. Things like bios strings and 
certainly the bits we currently pass in via the hvm_info_page could go through 
xenstore. But of course the types of things I am passing here really have no 
place in xenstore. So we could use the dual approach (which seems fine to me) 
or we could pass everything in as another module type directly into guest 
memory.

If we use xenstore I think we should wrap it up a bit. In the process of doing 
this patch set I wrote a hvm assist library that builds the modules (which you 
may also want upstream). This might be a good place to put an API to sort of 
codify what can be set for hvmloader's consumption.

And FYI I am more than willing to work on these things and help replace the 
info page.

Thanks
Ross

> -----Original Message-----
> From: Keir Fraser [mailto:keir.xen@xxxxxxxxx]
> Sent: Monday, March 19, 2012 7:45 PM
> To: Ross Philipson; xen-devel@xxxxxxxxxxxxxxxxxxx
> Cc: Tim (Xen.org); Ian Campbell
> Subject: Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
> 
> On 19/03/2012 22:04, "Ross Philipson" <Ross.Philipson@xxxxxxxxxx> wrote:
> 
> > This patch series introduces support of loading HVMLOADER extension
> > modules into a guest. These modules can contain firmware information
> > that is used by HVMLOADER to modify a guests virtual firmware at
> > startup. These modules are only used by HVMLOADER.
> 
> There has been agreement, and work mainly by Tim, to get rid of our
> existing hvm_info_table structure. This is similar in some ways,
> communicating between builder and hvmloader via guest memory, but on
> major steroids.
> 
> Actually it looks like this also whacks some parameters through xenstore
> as well (which is the newer way that Tim had been adding). So is this
> some kludgy combination of old and new?
> 
> Would like feedback at least from Tim.
> 
>  -- Keir
> 
> > The HVM module framework is generic allowing it to load any number of
> > modules irrespective of the contents. The domain building code in
> > libxenguest reads the modules and loads them into the new guest. The
> > loading is done in what will become the guests low RAM area just
> > behind to load location for HVMLOADER. A header structure is
> > constructed which locates the module set and this header's base GPA is
> > passed to the HVMLOADER in the ECX:EDX registers. The early entry code
> > in HVMLOADER fetches these values and initializes module support.
> >
> > Currently two types of firmware information are recognized and
> > processed in the HVMLOADER though this could be extended.
> > 1. SMBIOS: The SMBIOS table building code will attempt to retrieve a
> > predefined set of tables it allows to be overridden by passed through
> > tables. If a match is found the passed in table will be used. In
> > addition the SMBIOS code will also enumerate and process as many
> > vendor defined tables (in the range of types 128 - 255) as are passed
> in.
> > 2. ACPI: Static and code (SSDTs) tables can be added to the set of
> > ACPI table built by HVMLOADER. The ACPI builder code will enumerate
> > passed in tables and add them at the end of the secondary table list.
> >
> > There are 7 patches in the series:
> > 01 - Add public HVM definitions header for firmware module passthrough
> > support.
> > 02 - Add module processing support in HVMLOADER.
> > 03 - Fetch module set base address and initialize module support.
> > 04 - Pass through support for SMBIOS.
> > 05 - Pass through support for ACPI.
> > 06 - Module file reading utility.
> > 07 - Xen control tools support for loading the firmware modules.
> >
> > Signed-off-by: Ross Philipson <ross.philipson@xxxxxxxxxx>
> >
> >
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
> 


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