[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon, Jan 16, 2017 at 09:09:55AM -0700, Jan Beulich wrote:
> >>> On 16.01.17 at 16:14, <roger.pau@xxxxxxxxxx> wrote:
> > 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.
> 
> I don't understand this reply of yours: How do any ACPI requirements
> come into play when using the PV hotplug mechanism for vCPU-s?

This clearly isn't a requirement when doing PV vCPU hotplug, but it's a
violation of the spec (proving x2APIC entries without matching processor
objects), so I wouldn't be surprised if ACPICA or any other ACPI implementation
refuses to boot on systems with x2APIC entries but no processor objects.

Roger.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.