[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Arm: cpu_*_map adjustments
- To: Jan Beulich <jbeulich@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: "Orzel, Michal" <michal.orzel@xxxxxxx>
- Date: Wed, 16 Apr 2025 12:20:04 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=NuNtH+EnMnWBa/rH5TgPgiO3R0wwuDoy/S/pDzO7jGQ=; b=Lvyyq01f6pGBPA/Hv03Ow2KKZLcLSgIre1pQ4cieyrIs4jkYa5tcr9xqHxsTXoShWOkFb9MI5eNQYFLnTPaQOy2wtwhmS2znrgf40rCRuzTWeecXJtSpYmHeTW3hxlQzm+dh+j3s6aPMR4U/sdiNb5YebWDe1HgJPEAJhZFV4gjE/WQYrE0HmAotMWkwGSCxVG744F8eVfsZ+aI/VtZnRrghS4SpDkD213Tx7rkjr4GpVsXLeq0nWXP4Z7mozfdCmIjjDs+yzxb5EqAZtA2uFt+Rg7whvnvNs2FYeYw8heSpxHiW1zT5iPYN6cFq3hRJogH30KJaCV8Da4Imy3jivw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=cAia8qxaWbMruGZolzULVdaRR0dDXYeZXWYsb8KLMNuJfi6/T4OKgDPFqGqjD2KfnDsoaypiAlecmli5MFaJwK3vMZ1VX+Txv9gbgIuxbFpSfgDR7b9H3UvYdcT7pWxqTch48i6ctQDjOh9B4CJwyJ2Ez+a8Wlvam25qiHTxCVhbO6J3VSVJcgUrJd1mYzG8DbgOrhg+eDVD3RJJVH04sa9ejMOyDHJVzFeaIZ7GNS64S8GCMm7ex87wJCEfsMu45DwcllLzszL5YYfvLZoRgjWVtsDcsiiCRNXkYRdEHYRb0bTJ7rn/o4zwuj6HkR/naAouw9b1nQNt2wNv2+7eLw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
- Cc: Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
- Delivery-date: Wed, 16 Apr 2025 10:20:22 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 10/04/2025 16:54, Jan Beulich wrote:
> First, they all start out zeroed. There's no point doing an initial
> cpumask_clear() on them.
>
> Next, only cpu_online_map may be altered post-boot, and even that only
> rarely. Add respective placement attributes.
>
> Finally, cpu_present_map really isn't anything more than an alias of
> cpu_possible_map. Avoid the copying, and have the linker provide the
> symbol (if needed in the first place; it is needed right now as
> common code references the symbol).
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
Reviewed-by: Michal Orzel <michal.orzel@xxxxxxx>
> ---
> I would have preferred to use __attribute__((alias(...))), but that
> apparently (and following the doc) can't be used when a declaration of
> the to-be-provided symbol is present earlier.
>
> With the cpumask_clear()s dropped, the containing function's name is
> now yet more out of sync with what the function does. On x86 we call a
> similar thing smp_prepare_boot_cpu().
I agree the function name no longer makes sense. I'd be ok with renaming it to
smp_prepare_boot_cpu().
~Michal
|
