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

From: Roger Pau Monne <roger.pau@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	boris.ostrovsky@oracle.com, xen-devel@lists.xenproject.org
Subject: Re: [PATCH v4 14/14] xen/x86: setup PVHv2 Dom0 ACPI tables
Date: Thu, 22 Dec 2016 12:17:22 +0000	[thread overview]
Message-ID: <20161222121722.qav7k546yyf5waso@dhcp-3-221.uk.xensource.com> (raw)
In-Reply-To: <585BC100020000780012B9DA@prv-mh.provo.novell.com>

On Thu, Dec 22, 2016 at 04:03:12AM -0700, Jan Beulich wrote:
> >>> 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:
> >> > 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