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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 01/17/2017 09:44 AM, Jan Beulich wrote:
>>>> On 17.01.17 at 15:13, <roger.pau@xxxxxxxxxx> wrote:
>> On Tue, Jan 17, 2017 at 05:33:41AM -0700, Jan Beulich wrote:
>>>>>> On 17.01.17 at 12:43, <roger.pau@xxxxxxxxxx> wrote:
>>>> If the PVH domain has access to an APIC and wants to use it it must parse 
>>>> the
>>>> info from the MADT, or else it cannot get the APIC address or the APIC ID 
>>>> (you
>>>> could guess those, since their position is quite standard, but what's the
>>>> point?)
>>> There's always the option of obtaining needed information via hypercall.
>> I think we should avoid that and instead use ACPI only, or else we are
>> duplicating the information provided in ACPI using another interface, which 
>> is
>> pointless IMHO.
>>
>> 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?

-boris


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