loading custom ACPI tables?

loading custom ACPI tables?

[Eric Shelton]

For some items I am working on, I need to modify a couple of the ACPI
tables.  Is there a preexisting way to provide replacement tables that
will be used by the hypervisor and dom0?

Thanks,
Eric

Re: loading custom ACPI tables?

[Jan Beulich]

>>> On 21.04.13 at 19:25, Eric Shelton <eshelton@pobox.com> wrote:
> For some items I am working on, I need to modify a couple of the ACPI
> tables.  Is there a preexisting way to provide replacement tables that
> will be used by the hypervisor and dom0?

For the hypervisor - no. But you'll not normally need to modify the
(few) tables the hypervisor looks at.

For the kernel, iirc support had been floating around for quite some
time and got added relatively recently upstream (see
CONFIG_ACPI_INITRD_TABLE_OVERRIDE). Plus there has been,
for quite a bit longer a period already, a config option to add a DSDT
replacement at build time (CONFIG_ACPI_CUSTOM_DSDT{,_FILE}).

Jan

Re: loading custom ACPI tables?

[Eric Shelton]

Unfortunately, I managed to hit the few portions looked at by the
hypervisor, as I am modifying the IOAPIC information in MADT and IVRS
(as well as PCI slot interrupt info in DSDT, although that does not
appear to be looked at by the hypervisor).

A question on how Xen gathers platform info: Xen appears to use the MP
tables as a starting point for determining the number of IOAPICs.  Is
the hypervisor code capable of not using the MP tables, and solely
collecting this information from ACPI?  It would be nice not to

In terms of implementing passing in custom ACPI tables, I was
considering adding an additional "module" line in the grub
configuration (assuming a third one is permitted) to essentially a
copy of the in-memory structure, and looking for a magic number (which
will likely already be part of the ACPI tables).  I am aware of, but I
have not reviewed, the Linux initrd-based override code.  However, I'm
not sure whether the Xen development philosophy would prefer (1) code
reuse (if reasonably portable), even if it involves adding something
with the complexity of digging through an initrd; or (2) something
simpler with fewer LOC.  Other suggestions are welcome.

- Eric


On Mon, Apr 22, 2013 at 3:21 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 21.04.13 at 19:25, Eric Shelton <eshelton@pobox.com> wrote:
>> For some items I am working on, I need to modify a couple of the ACPI
>> tables.  Is there a preexisting way to provide replacement tables that
>> will be used by the hypervisor and dom0?
>
> For the hypervisor - no. But you'll not normally need to modify the
> (few) tables the hypervisor looks at.
>
> For the kernel, iirc support had been floating around for quite some
> time and got added relatively recently upstream (see
> CONFIG_ACPI_INITRD_TABLE_OVERRIDE). Plus there has been,
> for quite a bit longer a period already, a config option to add a DSDT
> replacement at build time (CONFIG_ACPI_CUSTOM_DSDT{,_FILE}).
>
> Jan
>

Re: loading custom ACPI tables?

[Jan Beulich]

>>> On 22.04.13 at 12:48, Eric Shelton <eshelton@pobox.com> wrote:
> Unfortunately, I managed to hit the few portions looked at by the
> hypervisor, as I am modifying the IOAPIC information in MADT and IVRS
> (as well as PCI slot interrupt info in DSDT, although that does not
> appear to be looked at by the hypervisor).

So I guess you're trying to work around the fallout of XSA-36?

> A question on how Xen gathers platform info: Xen appears to use the MP
> tables as a starting point for determining the number of IOAPICs.  Is
> the hypervisor code capable of not using the MP tables, and solely
> collecting this information from ACPI?  It would be nice not to

No, the MP tables should get looked at consulted only when there's
no respective ACPI data.

> In terms of implementing passing in custom ACPI tables, I was
> considering adding an additional "module" line in the grub
> configuration (assuming a third one is permitted) to essentially a
> copy of the in-memory structure, and looking for a magic number (which
> will likely already be part of the ACPI tables).  I am aware of, but I
> have not reviewed, the Linux initrd-based override code.  However, I'm
> not sure whether the Xen development philosophy would prefer (1) code
> reuse (if reasonably portable), even if it involves adding something
> with the complexity of digging through an initrd; or (2) something
> simpler with fewer LOC.  Other suggestions are welcome.

More than two modules is possible, and in fact already being used
(for XSM an microcode loading), so you'd need to look at the code
that's already there to make sure your ACPI table pseudo module(s)
won't get mistreated.

You certainly should not look at the initrd - format and contents
are defined/used by the kernel, hence no assumptions should be
made.

Jan

Re: loading custom ACPI tables?

[Eric Shelton]

On Apr 22, 2013, at 7:15 AM, Jan Beulich <JBeulich@suse.com> wrote:

>>>> On 22.04.13 at 12:48, Eric Shelton <eshelton@pobox.com> wrote:
>> Unfortunately, I managed to hit the few portions looked at by the
>> hypervisor, as I am modifying the IOAPIC information in MADT and IVRS
>> (as well as PCI slot interrupt info in DSDT, although that does not
>> appear to be looked at by the hypervisor).
>
> So I guess you're trying to work around the fallout of XSA-36?
>
It is related, but is not what is motivating the effort.  I have an
AMD 970-based motherboard for which the IOAPICs are misconfigured.
There are NB and SB ones, but the NB IOAPIC is not configured or
enabled, leaving all NB devices going through 4 SB GSIs, which further
are used by some SB devices.  Essentially no interrupt is unshared,
which is ridiculous on a system with 56 available GSIs.  At least the
BIOS seems to configure the IOMMU OK.  It would be nice for the MB
vendor to update the BIOS, but that doesn't seem to be going anywhere.
 Since configuring both IOAPICs properly looks easy enough, I'll give
it a try.

This could probably be done for any AMD 700+ chipset (although I'm not
sure how hard dynamic ACPI rewriting is, which would need to be done
at least to identify the changed GSIs), but I don't know how many
quirks-like things Xen is interested in accumulating.

>> A question on how Xen gathers platform info: Xen appears to use the MP
>> tables as a starting point for determining the number of IOAPICs.  Is
>> the hypervisor code capable of not using the MP tables, and solely
>> collecting this information from ACPI?  It would be nice not to
>
> No, the MP tables should get looked at consulted only when there's
> no respective ACPI data.
>
That is good to hear.  One set of such tables is enough to sort out...

>> In terms of implementing passing in custom ACPI tables, I was
>> considering adding an additional "module" line in the grub
>> configuration (assuming a third one is permitted) to essentially a
>> copy of the in-memory structure, and looking for a magic number (which
>> will likely already be part of the ACPI tables).  I am aware of, but I
>> have not reviewed, the Linux initrd-based override code.  However, I'm
>> not sure whether the Xen development philosophy would prefer (1) code
>> reuse (if reasonably portable), even if it involves adding something
>> with the complexity of digging through an initrd; or (2) something
>> simpler with fewer LOC.  Other suggestions are welcome.
>
> More than two modules is possible, and in fact already being used
> (for XSM an microcode loading), so you'd need to look at the code
> that's already there to make sure your ACPI table pseudo module(s)
> won't get mistreated.
>
Thank you for the pointer- I'll take a look.

> You certainly should not look at the initrd - format and contents
> are defined/used by the kernel, hence no assumptions should be
> made.
>
> Jan
>

Finally, am I correct in thinking that I need to make sure dom0 sees
the replacement ACPI table?  Since I will be changing the slot to GSI
mapping, it would seem necessary for dom0 drivers to get matched up
with their device interrupts.

- Eric

Re: loading custom ACPI tables?

[Jan Beulich]

>>> On 22.04.13 at 15:53, Eric Shelton <knockknock@gmail.com> wrote:
> Finally, am I correct in thinking that I need to make sure dom0 sees
> the replacement ACPI table?  Since I will be changing the slot to GSI
> mapping, it would seem necessary for dom0 drivers to get matched up
> with their device interrupts.

Yes, absolutely.

Jan