On Thu, Dec 22, 2016 at 04:03:12AM -0700, Jan Beulich wrote: > >>> On 22.12.16 at 11:43, <roger....@citrix.com> wrote: > > On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote: > >> > Since Xen is the one that sets the local APIC address in the MADT, and it > >> > always matches the position of the emulated local APIC I don't see why > >> > we would > >> > want to use acpi_madt_local_apic_override. I see that your worries are > >> > related > >> > to what would happen if AML tries to modify the MADT, but wouldn't in > >> > that case > >> > modify the native MADT, instead of the crafted one? > >> > >> Exactly, so how would you see the modification to get > >> propagated? > > > > Please bear with me, by modifications here do you mean what the _MAT method > > returns from processor objects? > > > > The ACPI 6.1 spec has something that worries me quite a lot (page 145): > > > > " > > a) When _MAT (see Section 6.2.10) appears under a Processor Device object > > (see > > Section 8.4), OSPM processes the Interrupt Controller Structures returned by > > _MAT with the types labeled "yes" and ignores other types. > > > > b) When _MAT appears under an I/O APIC Device (see Section 9.17), OSPM > > processes the Interrupt Controller Structures returned by _MAT with the > > types > > labeled "yes" and ignores other types. > > " > > > > Which from my understanding means that almost everything from the original > > MADT > > can be overwritten by the returns of _MAT methods. The same seems to be true > > for ARM, and I don't see them dealing with this in any way. Is this > > something > > that has yet to be implemented by any vendor? > > I don't understand. For one, I can't see the spec requiring or excluding > the in place modification of MADT entries for the purpose of implementing > _MAT. Which route is taken is imo an implementation choice. In hvmloader > we use the in place modification approach at present. And then looking > at the original MADT is a boot time thing, so subsequent modifications > should be of no interest to the OS (they'd get those as _MAT return > values, not by looking at the static table). > > The thing that I'm worried about is a physical machine's firmware using > the same approach as we do in hvmloader, thus returning from _MAT > values which are out of sync with the MADT we present to Dom0. > Although - thinking about it a second time now, we'd have the same > inconsistency issue if the firmware constructed the _MAT return > values from scratch, so this will need dealing with in any case for > CPU hotplug to work.
I don't see an obvious solution to this, those _MAT methods reside in AML, and ATM Xen has no way to parse, much even less modify this code. Xen could add the Processor device path to the STAO so that Dom0 ignores them, but that would also prevent ACPI CPU hotplug from working in Dom0. Maybe Boris has some ideas about how to do CPU hotplug for Dom0? Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
