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
>>> 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
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 >
>>> 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 toNo, 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
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
>>> 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