|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] PVH CPU hotplug design document
>>> On 17.01.17 at 16:27, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 01/17/2017 09:44 AM, Jan Beulich wrote:
>>>>> On 17.01.17 at 15:13, <roger.pau@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |