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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.01.17 at 02:44, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 01/13/2017 10:51 AM, 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.
> 
> 
> 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)?

I'm not sure I understand especially the first question, and it's not
clear a rewrite of what (Xen, tools, OSes) you allude to in the second.
In the end, anything can be added later (so the answer to question 1
would be yes no matter what, without further qualification).

Jan


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