Re: [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables

["Jan Beulich" <JBeulich@suse.com>]

>>> On 22.12.16 at 11:43, <roger.pau@citrix.com> wrote:
> On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
>> I'm not convinced these table entries are tied to >255 CPUs - I'm
>> seeing them on systems with far less. Hence I simply wonder what
>> functionality we may miss to offer to OSes with these tables
>> absent.
> 
> From the ACPI spec, both entries looks very similar, with the exception that
> the x2APIC entry has a bigger size (from 1byte to 4bytes) for both the
> processor and the APIC ID.
> 
> I don't have a system with x2APIC entries at hand, but I guess the easiest way
> to solve this would be to add x2APIC and x2APIC NMI entries if they are also
> present on the native MADT?

Yes, that might be a good basis for determining, at least for now.
Otoh we always emulate an x2APIC, so it may not be unreasonable
to always provide these entries in parallel with the legacy LAPIC
ones.

> Could it be that your systems provide those entries because the firmware is
> shared with other high-end boxes or prepared to handle configurations with >255
> APIC IDs?

I obviously don't know (and hence can't exclude) that.

>> >> I can kind of see struct acpi_madt_local_apic_override not being
>> > 
>> > 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.

Jan


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