Re: PVH CPU hotplug design document

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

On 01/13/2017 10:51 AM, Jan Beulich wrote:
>>>> On 12.01.17 at 13:13, <roger.pau@citrix.com> 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.


Can the changes that Roger proposed here be added later? Will they
require a major rewrite of what we have now (or will soon have) for dom0
or is it just adding new code (mostly)?

-boris


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