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

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 12/22/2016 11:44 AM, Roger Pau Monne wrote:
> 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.

By "unmodified _MAT" you mean system's _MAT?  Why can't we provide our
own that will return _MAT object properly adjusted for dom0? We are
going to provide our own (i.e. not system's) DSDT, aren't we?

> 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).

So the problem seems to be that we need to run both _MATs --- system's
and dom0's.


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


I would very much like to avoid this.

-boris



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