Re: [Xen-devel] loading custom ACPI tables?

[Eric Shelton <knockknock@xxxxxxxxx>]

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

>>>> On 22.04.13 at 12:48, Eric Shelton <eshelton@xxxxxxxxx> 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

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