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

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Wed, Dec 21, 2016 at 10:04:20AM -0700, Jan Beulich wrote:
> >>> On 21.12.16 at 17:32, <roger.pau@xxxxxxxxxx> wrote:
> > On Mon, Dec 12, 2016 at 06:56:36AM -0700, Jan Beulich wrote:
> >> >>> On 30.11.16 at 17:49, <roger.pau@xxxxxxxxxx> wrote:
> >> > +static int __init hvm_setup_acpi_madt(struct domain *d, paddr_t *addr)
> >> > +{
> >> > +    struct acpi_table_madt *madt;
> >> > +    struct acpi_table_header *table;
> >> > +    struct acpi_madt_io_apic *io_apic;
> >> > +    struct acpi_madt_local_apic *local_apic;
> >> 
> >> I think I had asked about the absence of struct acpi_madt_local_x2apic
> >> here before, but now that I look again I also wonder how you get away
> >> without struct acpi_madt_nmi_source and struct acpi_madt_local_apic_nmi;
> > 
> > Since we are currently limited to 128 vCPUs (max APIC ID 255), I don't think
> > acpi_madt_local_x2apic is required in this scenario:
> > 
> > https://lists.xen.org/archives/html/xen-devel/2016-11/msg02815.html 
> > 
> > I will work on adding those entries once that limit is lifted, would you be
> > fine with me adding a comment here regarding the no-need of
> > acpi_madt_local_x2apic until support for > 128vCPUs is added?
> 
> 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?

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 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?

Roger.


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