Re: [Xen-devel] PVH CPU hotplug design document

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Fri, Jan 13, 2017 at 08:51:57AM -0700, Jan Beulich wrote:
> >>> On 12.01.17 at 13:13, <roger.pau@xxxxxxxxxx> wrote:
> > # Introduction
> > 
> > One of the design goals of PVH is to be able to remove as much Xen PV 
> > specific
> > code as possible, thus limiting the number of Xen PV interfaces used by 
> > guests,
> > and tending to use native interfaces (as used by bare metal) as much as
> > possible. This is in line with the efforts also done by Xen on ARM and helps
> > reduce the burden of maintaining huge amounts of Xen PV code inside of 
> > guests
> > kernels.
> > 
> > This however presents some challenges due to the model used by the Xen
> > Hypervisor, where some devices are handled by Xen while others are left for 
> > the
> > hardware domain to manage. The fact that Xen lacks and AML parser also 
> > makes it
> > harder, since it cannot get the full hardware description from dynamic ACPI
> > tables (DSDT, SSDT) without the hardware domain collaboration.
> 
> Considering all the difficulties with the proposed model plus the little
> code the PV vCPU hotplug logic requires in the kernel (assuming a
> xenbus driver to be there anyway), I'm rather unconvinced that
> going this route instead of sticking to the PV model is actually
> desirable. And clearly, for consistency within the kernel, in such a
> case I'd then also favor sticking to this model for DomU.

We would at least have to pass the APIC ID in order to perform vCPU hotplug for
PVH, and the ACPI spec mandates that when using x2APIC structures in the MADT,
there must be a matching processor object in the DSDT (5.2.12.12).

Declaring processor objects in the DSDT won't be possible for Xen, but we can
at least declare them in a SSDT, which seems better than not doing it at all.
Maybe we can get ACPI to loosen the spec and don't mandate DSDT anymore.

Roger.

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