Re: [PATCH 2/2] viridian: allow vCPU hotplug for Windows VMs

[Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>]

On 08/01/2021 11:33, Paul Durrant wrote:
>> -----Original Message-----
>> From: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
>> Sent: 08 January 2021 11:30
>> To: paul@xxxxxxx; xen-devel@xxxxxxxxxxxxxxxxxxxx
>> Cc: wl@xxxxxxx; iwj@xxxxxxxxxxxxxx; anthony.perard@xxxxxxxxxx; 
>> andrew.cooper3@xxxxxxxxxx;
>> george.dunlap@xxxxxxxxxx; jbeulich@xxxxxxxx; julien@xxxxxxx; 
>> sstabellini@xxxxxxxxxx;
>> roger.pau@xxxxxxxxxx
>> Subject: Re: [PATCH 2/2] viridian: allow vCPU hotplug for Windows VMs
>>
>> On 08/01/2021 08:38, Paul Durrant wrote:
>>>> -----Original Message-----
>>>> From: Igor Druzhinin <igor.druzhinin@xxxxxxxxxx>
>>>> Sent: 08 January 2021 00:47
>>>> To: xen-devel@xxxxxxxxxxxxxxxxxxxx
>>>> Cc: paul@xxxxxxx; wl@xxxxxxx; iwj@xxxxxxxxxxxxxx; 
>>>> anthony.perard@xxxxxxxxxx;
>>>> andrew.cooper3@xxxxxxxxxx; george.dunlap@xxxxxxxxxx; jbeulich@xxxxxxxx; 
>>>> julien@xxxxxxx;
>>>> sstabellini@xxxxxxxxxx; roger.pau@xxxxxxxxxx; Igor Druzhinin 
>>>> <igor.druzhinin@xxxxxxxxxx>
>>>> Subject: [PATCH 2/2] viridian: allow vCPU hotplug for Windows VMs
>>>>
>>>> If Viridian extensions are enabled, Windows wouldn't currently allow
>>>> a hotplugged vCPU to be brought up dynamically. We need to expose a special
>>>> bit to let the guest know we allow it. It appears we can just start 
>>>> exposing
>>>> it without worrying too much about compatibility - see relevant QEMU
>>>> discussion here:
>>>>
>>>> https://patchwork.kernel.org/project/qemu-devel/patch/1455364815-19586-1-git-send-email-
>>>> den@xxxxxxxxxx/
>>>
>>> I don't think that discussion really confirmed it was safe... just that 
>>> empirically it appeared to
>> be so. I think we should err on
>>> the side of caution and have this behind a feature flag (but I'm happy for 
>>> it to default to on).
>>
>> QEMU was having this code since 2016 and nobody complained is good
>> enough for me - but if you insist we need an option - ok, I will add one.
>>
> 
> Given that it has not yet been in a release, perhaps you could just guard 
> this and the implementation of leaf 0x40000005 using HVMPV_ex_processor_masks?

That looks sloppy and confusing to me - let's have a separate option instead.

Igor