Re: [PATCH] x86/Xen: streamline (and fix) PV CPU enumeration

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.02.2022 15:27, Boris Ostrovsky wrote:
> 
> On 2/1/22 5:57 AM, Jan Beulich wrote:
>> This started out with me noticing that "dom0_max_vcpus=<N>" with <N>
>> larger than the number of physical CPUs reported through ACPI tables
>> would not bring up the "excess" vCPU-s. Addressing this is the primary
>> purpose of the change; CPU maps handling is being tidied only as far as
>> is necessary for the change here (with the effect of also avoiding the
>> setting up of too much per-CPU infrastructure, i.e. for CPUs which can
>> never come online).
>>
>> Noticing that xen_fill_possible_map() is called way too early, whereas
>> xen_filter_cpu_maps() is called too late (after per-CPU areas were
>> already set up), and further observing that each of the functions serves
>> only one of Dom0 or DomU, it looked like it was better to simplify this.
>> Use the .get_smp_config hook instead, uniformly for Dom0 and DomU.
>> xen_fill_possible_map() can be dropped altogether, while
>> xen_filter_cpu_maps() is re-purposed but not otherwise changed.
>>
>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>> v2: Extend description.
> 
> 
> That's been a while ;-)

Indeed. For some reason I had stored in the back of my memory that
you asked me for splitting the patch. That's something that would
have required at least as much time (to make sure I get it right)
as it took to put together (and test) the patch. Which was more
than I could afford in all this time. Recently I decided to check
with you whether I could talk you into withdrawing that (supposed)
request. But when going back through the old thread, I was
surprised to find that all you did ask for is extending the
description to point out that the CPU map management isn't the
primary purpose of the change.

> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>

Thanks.

Jan