This patch series introduces support of loading external blocks of firmware into a guest. These blocks can currently contain SMBIOS and/or ACPI firmware information that is used by HVMLOADER to modify a guests virtual firmware at startup. These modules are only used by HVMLOADER and are effectively discarded after HVMLOADER has completed. The domain building code in libxenguest is passed these firmware blocks in the xc_hvm_build_args structure and loads them into the new guest, returning the load address. The loading is done in what will become the guests low RAM area just behind to load location for HVMLOADER. After their use by HVMLOADER they are effectively discarded. It is the caller''s job to load the base address and length values in xenstore using the paths defined in the new hvm_defs.h header so HVMLOADER can located the blocks. 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 (for predefined set of structure types) any passed in structures. If a match is found the passed in table will be used overriding the default values. In addition, the SMBIOS code will also enumerate and load any vendor defined strutures (in the range of types 128 - 255) that as are passed in. See the hvm_defs.h header for information on the format of this block. 2. ACPI: Static and secondary descriptor 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. See the hvm_defs.h header for information on the format of this block. There are 4 patches in the series: 01 - Add HVM definitions header for firmware passthrough support. 02 - Xen control tools support for loading the firmware blocks. 03 - Passthrough support for SMBIOS. 04 - Passthrough support for ACPI. Note this is version 3 of this patch set. Some of the differences: - Generic module support removed, overall functionality was simplified. - Use of xenstore to supply firmware passthrough information to HVMLOADER. - Fixed issues pointed out in the SMBIOS processing code. - Created defines for the SMBIOS handles in use and switched to using the xenstore values in the new hvm_defs.h file. Signed-off-by: Ross Philipson <ross.philipson@citrix.com> (Based on xen-4.3 staging/unstable cs 26317)
On Thu, Dec 20, 2012 at 01:55:10PM -0500, Ross Philipson wrote:> This patch series introduces support of loading external blocks of firmware > into a guest. These blocks can currently contain SMBIOS and/or ACPI firmware > information that is used by HVMLOADER to modify a guests virtual firmware at > startup. These modules are only used by HVMLOADER and are effectively discarded after HVMLOADER has completed. > > The domain building code in libxenguest is passed these firmware blocks > in the xc_hvm_build_args structure and loads them into the new guest, > returning the load address. The loading is done in what will become the guests > low RAM area just behind to load location for HVMLOADER. After their use by > HVMLOADER they are effectively discarded. It is the caller''s job to load the > base address and length values in xenstore using the paths defined in the new > hvm_defs.h header so HVMLOADER can located the blocks. >Are there patches to plug this in the ''xl''?> 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 (for > predefined set of structure types) any passed in structures. If a match is > found the passed in table will be used overriding the default values. In > addition, the SMBIOS code will also enumerate and load any vendor defined > strutures (in the range of types 128 - 255) that as are passed in. See the > hvm_defs.h header for information on the format of this block. > 2. ACPI: Static and secondary descriptor 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. See the hvm_defs.h > header for information on the format of this block. > > There are 4 patches in the series: > 01 - Add HVM definitions header for firmware passthrough support. > 02 - Xen control tools support for loading the firmware blocks. > 03 - Passthrough support for SMBIOS. > 04 - Passthrough support for ACPI. > > Note this is version 3 of this patch set. Some of the differences: > - Generic module support removed, overall functionality was simplified. > - Use of xenstore to supply firmware passthrough information to HVMLOADER. > - Fixed issues pointed out in the SMBIOS processing code. > - Created defines for the SMBIOS handles in use and switched to using > the xenstore values in the new hvm_defs.h file. > > Signed-off-by: Ross Philipson <ross.philipson@citrix.com> > > (Based on xen-4.3 staging/unstable cs 26317) > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >
> -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Friday, December 21, 2012 2:46 PM > To: Ross Philipson > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > On Thu, Dec 20, 2012 at 01:55:10PM -0500, Ross Philipson wrote: > > This patch series introduces support of loading external blocks of > > firmware into a guest. These blocks can currently contain SMBIOS > > and/or ACPI firmware information that is used by HVMLOADER to modify a > > guests virtual firmware at startup. These modules are only used by > HVMLOADER and are effectively discarded after HVMLOADER has completed. > > > > The domain building code in libxenguest is passed these firmware > > blocks in the xc_hvm_build_args structure and loads them into the new > > guest, returning the load address. The loading is done in what will > > become the guests low RAM area just behind to load location for > > HVMLOADER. After their use by HVMLOADER they are effectively > > discarded. It is the caller''s job to load the base address and length > > values in xenstore using the paths defined in the new hvm_defs.h > header so HVMLOADER can located the blocks. > > > > Are there patches to plug this in the ''xl''? >So far there are only patches to expose it at the xc layer. Nothing else seems to use the xc_hvm_build() call (only xc_hvm_build_target_mem()). Since the use of this feature seems dependent on a user''s particular needs, I am not sure how it could generically be built into xl. Any suggestions are welcome though and I could post subsequent patches. Thanks Ross
On Fri, Dec 21, 2012 at 06:31:58PM -0500, Ross Philipson wrote:> > -----Original Message----- > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > > Sent: Friday, December 21, 2012 2:46 PM > > To: Ross Philipson > > Cc: xen-devel@lists.xensource.com > > Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > > > On Thu, Dec 20, 2012 at 01:55:10PM -0500, Ross Philipson wrote: > > > This patch series introduces support of loading external blocks of > > > firmware into a guest. These blocks can currently contain SMBIOS > > > and/or ACPI firmware information that is used by HVMLOADER to modify a > > > guests virtual firmware at startup. These modules are only used by > > HVMLOADER and are effectively discarded after HVMLOADER has completed. > > > > > > The domain building code in libxenguest is passed these firmware > > > blocks in the xc_hvm_build_args structure and loads them into the new > > > guest, returning the load address. The loading is done in what will > > > become the guests low RAM area just behind to load location for > > > HVMLOADER. After their use by HVMLOADER they are effectively > > > discarded. It is the caller''s job to load the base address and length > > > values in xenstore using the paths defined in the new hvm_defs.h > > header so HVMLOADER can located the blocks. > > > > > > > Are there patches to plug this in the ''xl''? > > > > So far there are only patches to expose it at the xc layer. Nothing else > seems to use the xc_hvm_build() call (only xc_hvm_build_target_mem()). > Since the use of this feature seems dependent on a user''s particular > needs, I am not sure how it could generically be built into xl. Any > suggestions are welcome though and I could post subsequent patches.I was thinking something like this: firmware="nvidia.bin" acpi_dsdt="acpi.dsdt" ?> > Thanks > Ross
> -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Friday, December 21, 2012 9:12 PM > To: Ross Philipson > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > On Fri, Dec 21, 2012 at 06:31:58PM -0500, Ross Philipson wrote: > > > -----Original Message----- > > > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > > > Sent: Friday, December 21, 2012 2:46 PM > > > To: Ross Philipson > > > Cc: xen-devel@lists.xensource.com > > > Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > > > > > On Thu, Dec 20, 2012 at 01:55:10PM -0500, Ross Philipson wrote: > > > > This patch series introduces support of loading external blocks of > > > > firmware into a guest. These blocks can currently contain SMBIOS > > > > and/or ACPI firmware information that is used by HVMLOADER to > modify a > > > > guests virtual firmware at startup. These modules are only used by > > > HVMLOADER and are effectively discarded after HVMLOADER has > completed. > > > > > > > > The domain building code in libxenguest is passed these firmware > > > > blocks in the xc_hvm_build_args structure and loads them into the > new > > > > guest, returning the load address. The loading is done in what > will > > > > become the guests low RAM area just behind to load location for > > > > HVMLOADER. After their use by HVMLOADER they are effectively > > > > discarded. It is the caller''s job to load the base address and > length > > > > values in xenstore using the paths defined in the new hvm_defs.h > > > header so HVMLOADER can located the blocks. > > > > > > > > > > Are there patches to plug this in the ''xl''? > > > > > > > So far there are only patches to expose it at the xc layer. Nothing > else > > seems to use the xc_hvm_build() call (only xc_hvm_build_target_mem()). > > Since the use of this feature seems dependent on a user''s particular > > needs, I am not sure how it could generically be built into xl. Any > > suggestions are welcome though and I could post subsequent patches. > > I was thinking something like this: > > firmware="nvidia.bin" > acpi_dsdt="acpi.dsdt" >You are talking about values in the config that libxl consumes (I am not terribly familiar with libxl)? Yea I could do something like that. I don''t think in general anyone would override the entire DSDT (though I could add that support if desired). So I would probably do something like: smbios_pt="smbios_structures.bin" acpi_pt="acpi_tables.bin" In the process should I switch libxl to call xc_hvm_build() rather than xc_hvm_build_target_mem()?> ? > > > > Thanks > > Ross
On Sat, 2012-12-22 at 23:46 +0000, Ross Philipson wrote:> You are talking about values in the config that libxl consumes (I am > not terribly familiar with libxl)? Yea I could do something like that. > I don''t think in general anyone would override the entire DSDT (though > I could add that support if desired). So I would probably do something > like: > > smbios_pt="smbios_structures.bin" > acpi_pt="acpi_tables.bin" > > In the process should I switch libxl to call xc_hvm_build() > rather than xc_hvm_build_target_mem()?I think that would be preferable to extending the xc_hvm_build_target_mem API any further, iirc xc_hvm_build was intended to be the extensible replacement. Ian.
> -----Original Message----- > From: Ian Campbell > Sent: Wednesday, January 02, 2013 8:25 AM > To: Ross Philipson > Cc: Konrad Rzeszutek Wilk; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > On Sat, 2012-12-22 at 23:46 +0000, Ross Philipson wrote: > > > You are talking about values in the config that libxl consumes (I am > > not terribly familiar with libxl)? Yea I could do something like that. > > I don''t think in general anyone would override the entire DSDT (though > > I could add that support if desired). So I would probably do something > > like: > > > > smbios_pt="smbios_structures.bin" > > acpi_pt="acpi_tables.bin" > > > > In the process should I switch libxl to call xc_hvm_build() > > rather than xc_hvm_build_target_mem()? > > I think that would be preferable to extending the > xc_hvm_build_target_mem API any further, iirc xc_hvm_build was intended > to be the extensible replacement. > > Ian.Ok I will submit a separate patch (set) for changes to libxl. I will switch to using the new build function too. Thanks Ross
On 22/12/12 23:46, Ross Philipson wrote:> > In the process should I switch libxl to call xc_hvm_build() > rather than xc_hvm_build_target_mem()?Please. I''m not sure why I didn''t do this when I introduced xc_hvm_build()... Note the units of the mem_size and mem_target fields are in bytes (not MiB like the old functions). David
> -----Original Message----- > From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > bounces@lists.xen.org] On Behalf Of Ross Philipson > Sent: Thursday, December 20, 2012 1:55 PM > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > This patch series introduces support of loading external blocks of > firmware > into a guest. These blocks can currently contain SMBIOS and/or ACPI > firmware > information that is used by HVMLOADER to modify a guests virtual > firmware at > startup. These modules are only used by HVMLOADER and are effectively > discarded after HVMLOADER has completed.... Is there anything else I need to do to get this patch series accepted? Thanks Ross> _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Jan 8, 2013, at 3:26 PM, Ross Philipson <Ross.Philipson@citrix.com> wrote:>> -----Original Message----- >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- >> bounces@lists.xen.org] On Behalf Of Ross Philipson >> Sent: Thursday, December 20, 2012 1:55 PM >> To: xen-devel@lists.xensource.com >> Subject: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough >> >> This patch series introduces support of loading external blocks of >> firmware >> into a guest. These blocks can currently contain SMBIOS and/or ACPI >> firmware >> information that is used by HVMLOADER to modify a guests virtual >> firmware at >> startup. These modules are only used by HVMLOADER and are effectively >> discarded after HVMLOADER has completed. > ... > > Is there anything else I need to do to get this patch series accepted?Address the comments we had. I believe it was on making this be part of "xl" guest config parsing.> > Thanks > Ross > >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xen.org >> http://lists.xen.org/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >
> -----Original Message----- > From: Konrad Rzeszutek Will [mailto:ketuzsezr@gmail.com] > Sent: Tuesday, January 08, 2013 7:00 PM > To: Ross Philipson > Cc: xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > On Jan 8, 2013, at 3:26 PM, Ross Philipson <Ross.Philipson@citrix.com> > wrote: > > >> -----Original Message----- > >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > >> bounces@lists.xen.org] On Behalf Of Ross Philipson > >> Sent: Thursday, December 20, 2012 1:55 PM > >> To: xen-devel@lists.xensource.com > >> Subject: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > >> > >> This patch series introduces support of loading external blocks of > >> firmware > >> into a guest. These blocks can currently contain SMBIOS and/or ACPI > >> firmware > >> information that is used by HVMLOADER to modify a guests virtual > >> firmware at > >> startup. These modules are only used by HVMLOADER and are effectively > >> discarded after HVMLOADER has completed. > > ... > > > > Is there anything else I need to do to get this patch series accepted? > > Address the comments we had. I believe it was on making this be part of > "xl" guest config parsing.Oh I thought I did. I said I would submit a separate set of patches for the work in xl once the earlier bits were in. Is that not an acceptable approach? Thanks Ross> > > > Thanks > > Ross > > > >> _______________________________________________ > >> Xen-devel mailing list > >> Xen-devel@lists.xen.org > >> http://lists.xen.org/xen-devel > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xen.org > > http://lists.xen.org/xen-devel > >
On Tue, Jan 08, 2013 at 07:14:11PM -0500, Ross Philipson wrote:> > -----Original Message----- > > From: Konrad Rzeszutek Will [mailto:ketuzsezr@gmail.com] > > Sent: Tuesday, January 08, 2013 7:00 PM > > To: Ross Philipson > > Cc: xen-devel@lists.xensource.com > > Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > > > On Jan 8, 2013, at 3:26 PM, Ross Philipson <Ross.Philipson@citrix.com> > > wrote: > > > > >> -----Original Message----- > > >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > > >> bounces@lists.xen.org] On Behalf Of Ross Philipson > > >> Sent: Thursday, December 20, 2012 1:55 PM > > >> To: xen-devel@lists.xensource.com > > >> Subject: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > >> > > >> This patch series introduces support of loading external blocks of > > >> firmware > > >> into a guest. These blocks can currently contain SMBIOS and/or ACPI > > >> firmware > > >> information that is used by HVMLOADER to modify a guests virtual > > >> firmware at > > >> startup. These modules are only used by HVMLOADER and are effectively > > >> discarded after HVMLOADER has completed. > > > ... > > > > > > Is there anything else I need to do to get this patch series accepted? > > > > Address the comments we had. I believe it was on making this be part of > > "xl" guest config parsing. > > Oh I thought I did. I said I would submit a separate set of patches for > the work in xl once the earlier bits were in. Is that not an acceptable > approach?Somehow I missed that. I thought there were also comments on how the call to the library should be done? As in - not introduce a new one but alter the existing one? Or am I thinking of a different patchset?
> -----Original Message----- > From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com] > Sent: Wednesday, January 09, 2013 9:56 AM > To: Ross Philipson > Cc: Konrad Rzeszutek Will; xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > On Tue, Jan 08, 2013 at 07:14:11PM -0500, Ross Philipson wrote: > > > -----Original Message----- > > > From: Konrad Rzeszutek Will [mailto:ketuzsezr@gmail.com] > > > Sent: Tuesday, January 08, 2013 7:00 PM > > > To: Ross Philipson > > > Cc: xen-devel@lists.xensource.com > > > Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > > > > > On Jan 8, 2013, at 3:26 PM, Ross Philipson > <Ross.Philipson@citrix.com> > > > wrote: > > > > > > >> -----Original Message----- > > > >> From: xen-devel-bounces@lists.xen.org [mailto:xen-devel- > > > >> bounces@lists.xen.org] On Behalf Of Ross Philipson > > > >> Sent: Thursday, December 20, 2012 1:55 PM > > > >> To: xen-devel@lists.xensource.com > > > >> Subject: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > > >> > > > >> This patch series introduces support of loading external blocks > of > > > >> firmware > > > >> into a guest. These blocks can currently contain SMBIOS and/or > ACPI > > > >> firmware > > > >> information that is used by HVMLOADER to modify a guests virtual > > > >> firmware at > > > >> startup. These modules are only used by HVMLOADER and are > effectively > > > >> discarded after HVMLOADER has completed. > > > > ... > > > > > > > > Is there anything else I need to do to get this patch series > accepted? > > > > > > Address the comments we had. I believe it was on making this be part > of > > > "xl" guest config parsing. > > > > Oh I thought I did. I said I would submit a separate set of patches > for > > the work in xl once the earlier bits were in. Is that not an > acceptable > > approach? > > Somehow I missed that. I thought there were also comments on how the > call > to the library should be done? As in - not introduce a new one but alter > the existing one? Or am I thinking of a different patchset?I am not sure if that is related to my patches. I had brought up the point that the new xc_hvm_build() routine was never called from xl. I think the consensus was that I should remedy that in the process of adding the support for fw pass-through. I planned to do xl after the first patch set went in - are there any vetoes to that plan? Also since I will be adding parameters I suspect I need to update the docs on the xl configuration files. Any pointers on how to do that would be helpful. I see the man page source in docs/man/xl.cfg.pod.5; is the wiki information generated off of this? Thanks Ross
Ross Philipson writes ("Re: [Xen-devel] [PATCH v4 00/04] HVM firmware
passthrough"):> I am not sure if that is related to my patches. I had brought up the point
> that the new xc_hvm_build() routine was never called from xl. I think the
> consensus was that I should remedy that in the process of adding the
support
> for fw pass-through.
I think in general it is best to introduce new features in the whole
stack in the same series.
That way we don''t introduce code at lower layers only to discover
later that the higher layer wants something different.
> I planned to do xl after the first patch set went in - are there any vetoes
> to that plan? Also since I will be adding parameters I suspect I need to
> update the docs on the xl configuration files. Any pointers on how to do
that
> would be helpful. I see the man page source in docs/man/xl.cfg.pod.5; is
> the wiki information generated off of this?
How are you testing this series yourself if you don''t have a suitable
series for libxl/xl as well ?
Ian.
> -----Original Message----- > From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com] > Sent: Tuesday, February 12, 2013 10:47 AM > To: Ross Philipson > Cc: Konrad Rzeszutek Wilk; Konrad Rzeszutek Will; xen- > devel@lists.xensource.com > Subject: Re: [Xen-devel] [PATCH v4 00/04] HVM firmware passthrough > > Ross Philipson writes ("Re: [Xen-devel] [PATCH v4 00/04] HVM firmware > passthrough"): > > I am not sure if that is related to my patches. I had brought up the > point > > that the new xc_hvm_build() routine was never called from xl. I think > the > > consensus was that I should remedy that in the process of adding the > support > > for fw pass-through. > > I think in general it is best to introduce new features in the whole > stack in the same series. > > That way we don''t introduce code at lower layers only to discover > later that the higher layer wants something different.In the future I will do this.> > > I planned to do xl after the first patch set went in - are there any > vetoes > > to that plan? Also since I will be adding parameters I suspect I need > to > > update the docs on the xl configuration files. Any pointers on how to > do that > > would be helpful. I see the man page source in docs/man/xl.cfg.pod.5; > is > > the wiki information generated off of this? > > How are you testing this series yourself if you don''t have a suitable > series for libxl/xl as well ?I just had some hard coded test code that more or less behaved as the code I am submitting for libxl behaves.> > Ian.