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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.01.17 at 15:28, <boris.ostrovsky@xxxxxxxxxx> wrote:
> On 01/23/2017 05:35 AM, Jan Beulich wrote:
>>>>> On 22.01.17 at 19:39, <boris.ostrovsky@xxxxxxxxxx> wrote:
>>> On 01/18/2017 08:25 AM, Jan Beulich wrote:
>>>>>>> On 18.01.17 at 12:54, <roger.pau@xxxxxxxxxx> wrote:
>>>>> So, would it be fine to start a PVH Dom0 with as many vCPUs as what's 
>>>>> returned
>>>>> from dom0_max_vcpus, and mark them as enabled in the MADT. That's 
>>>>> basically all
>>>>> we need in order to match current PV Dom0 functionality?
>>>> Yes, I think so.
>>>
>>> Have we then decided that we are not supporting ACPI hotplug for both 
>>> dom0 and domU?
>> I don't think anything has been decided yet, it's just that the road to
>> (consistent) ACPI hotplug support still seems somewhat cloudy, so
>> getting there (if we're convinced this is a worthwhile goal) may still
>> take some time.
> 
> 
> I am mostly interested in domU support at this point. This is the only
> feature that I can think of right now that blocks domU support in Linux.
> 
> As I said in an earlier message I don't think dom0 needs ACPI hotplug
> (or hotplug at all) while domU would benefit from it. But perhaps by
> "consistent" you meant that you prefer both to behave in the same manner.

Yes.

> From Linux perspective one option could be to have domU with PV-style
> vCPU on/offlining based on xenstore and switch to ACPI hotplug if/when
> it becomes available. This, however, will need an indication from the
> hypervisor. We could, for example, set ACPI_FADT_HW_REDUCED, as we
> discussed earlier.

I think we shouldn't overload that flag. Didn't we settle already on using
two CPUID flags (of for PV-style onlining/offlining, the other for ACPI
hot(un)plug)? With that I think I could then be talked into accepting the
existence of two different models (and kernels could pick which one(s)
they would like to support).

Jan


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