Re: [Xen-devel] [RFC PATCH v2 06/16] libxl: Load guest ACPI table from file

[Anthony PERARD <anthony.perard@xxxxxxxxxx>]

On Wed, Nov 04, 2015 at 10:57:35AM +0000, Ian Campbell wrote:
> On Mon, 2015-10-26 at 16:03 +0000, Anthony PERARD wrote:
> > The path to the ACPI tables blob can be override by xl's option
> 
> "overridden"
> 
> > acpi_table_override or by acpi_tables_filename in the domain_build_info
> > struct for libxl user.
> 
> 
> This needs the same libxl.h #define and xl.cfg update I mentioned before.
> 
> The code, docs and commit message all need further consideration of the
> interactions with the existing acpi_firmware option which exists in libxl
> and is exposed in xl. It allows you to specify some extra tables which are
> merged (by hvmloader) into the base ones.
> 
> The naming is a bit unfortunate but we are now stuck with those semantics
> for the existing option I think. If we can distinguish partial from full
> tables in the tools reusing the name and doing so might be the best
> approach.
> 
> If we can't tell the difference then the new option needs some suitable
> name such that it is clear it is the full or base table or something.

We can probably tell the difference between both full and extra tables. I
think the full one should be a DSDT table, and the extra tables that can be
supplied by acpi_firmware should not be a DSDT.

So, if the AML supplied via acpi_firmware match 'DSDT' for it's signature
(the first four bytes), then it's a replacement for the full acpi tables.
Otherwise, it's probably extra tables, so we would give to hvmloader both
the default full acpi tables as well as the extra one from the user.

Would that be OK as an extention of the usage of acpi_firmware (in both
libxl and xl)? If user wants to supply both the DSDT and extra tables, it
would concatenate the extra tables to the DSDT, the DSDT tables should be
first.

-- 
Anthony PERARD

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