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

[Roger Pau Monne <roger.pau@citrix.com>]

On Thu, Dec 22, 2016 at 09:24:02AM -0700, Jan Beulich wrote:
> >>> On 22.12.16 at 17:17, <boris.ostrovsky@oracle.com> wrote:
> > On 12/22/2016 07:17 AM, Roger Pau Monne wrote:
> >> Maybe Boris has some ideas about how to do CPU hotplug for Dom0?
> > 
> > Why would Xen need to be able to parse the AML that is intended to be
> > executed by dom0? I'd think that all the hypervisor would need to do is
> > to load it into memory, not any different from how it's done for regular
> > guests.
> 
> Well, if Dom0 executed the unmodified _MAT, it would get back
> data relating to the physical CPU. Roger is overriding MADT to
> present virtual CPU information to Dom0, and this would likewise
> need to happen for the _MAT return value.

This is one of the problems with this Dom/Xen0 split brain problem that we
have, and cannot get away from.

To clarify a little bit, I'm not overwriting the original MADT in memory, so
Dom0 should still be able to access it if the implementation of _MAT returns
data from that area. AFAICT when plugging in a physical CPU (pCPU) into the
hardware, Dom0 should see "correct" data returned by the _MAT method. However
(as represented by the " I've used), this data will not match Dom0 vCPU
topology, and should not be used by Dom0 (only reported to Xen in order to
bring up the new pCPU).

Then the problem arises because we have no way to perform vCPU hotplug for
Dom0, not at least as it is done for DomU (using ACPI), so we would have to use
an out-of-band method in order to do vCPU hotplug for Dom0, which is a PITA.

Roger.

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