Re: PVH CPU hotplug design document

["Jan Beulich" <JBeulich@suse.com>]

>>> On 17.01.17 at 16:27, <boris.ostrovsky@oracle.com> wrote:
> On 01/17/2017 09:44 AM, Jan Beulich wrote:
>>>>> On 17.01.17 at 15:13, <roger.pau@citrix.com> wrote:
>>> There's only one kind of PVHv2 guest that doesn't require ACPI, and that guest
>>> type also doesn't have emulated local APICs. We agreed that this model was
>>> interesting from things like unikernels DomUs, but that's the only reason why
>>> we are providing it. Not that full OSes couldn't use it, but it seems
>>> pointless.
>> You writing things this way makes me notice another possible design
>> issue here: Requiring ACPI is a bad thing imo, with even bare hardware
>> going different directions for at least some use cases (SFI being one
>> example). Hence I think ACPI should - like on bare hardware - remain
>> an optional thing. Which in turn require _all_ information obtained from
>> ACPI (if available) to also be available another way. And this other
>> way might by hypercalls in our case.
> 
> 
> At the risk of derailing this thread: why do we need vCPU hotplug for
> dom0 in the first place? What do we gain over "echo {1|0} >
> /sys/devices/system/cpu/cpuX/online" ?
> 
> I can see why this may be needed for domUs where Xen can enforce number
> of vCPUs that are allowed to run (which we don't enforce now anyway) but
> why for dom0?

Good that you now ask this too - that's the PV hotplug mechanism,
and I've been saying all the time that this should be just fine for PVH
(Dom0 and DomU).

Jan


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