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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.01.17 at 17:31, <roger.pau@xxxxxxxxxx> wrote:
> 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.

Good point, but what do you suggest short of declaring PVH v2 Dom0
impossible to properly implement? I think that the idea of multiplexing
ACPI for different purposes is simply going too far. For PV there's no
such problem, as the Dom0 OS is expected to be aware that processor
information coming from ACPI is not applicable to the view on CPUs it
has (read: vCPU-s). And therefore, unless clean multiplexing is possible,
I think PVH will need to retain this requirement (at which point there's
no spec violation anymore).

Jan


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