>>> On 12.01.17 at 13:13, <roger....@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. Jan _______________________________________________ Xen-devel mailing list Xenfirstname.lastname@example.org https://lists.xen.org/xen-devel