[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 00/07] HVM firmware passthrough
At 23:44 +0000 on 19 Mar (1332200698), Keir Fraser wrote: > 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. My impression from the earlier discussions is that we're pasing largish blobs of binary BIOS goop around, which aren't suitable to go into xenstore. Dropping them in memory where HVMloader can pick them up seems reasonable. All the control-path stuff - what the blobs are, where they are &c, should go through Xenstore, though. I'll take a look at the patches in detail later in the week. Tim. > > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |