Re: [PATCH] arm64/mpam: Support partial-core boot for MPAM

[Zeng Heng <zengheng4@huawei.com>]

Hi Ben,

On 2026/2/2 19:34, Ben Horgan wrote:
> Hi Zeng,
> 
> On 2/2/26 09:16, Zeng Heng wrote:
>>
>>
>> On 2026/2/2 16:41, Zeng Heng wrote:
>>>
>>>
>>> On 2026/1/29 18:11, Ben Horgan wrote:
>>>> Hi Zeng,
>>>>
>>>> I think I've just managed to whitelist your email address. So, all being
>>>> well I'll get your emails in my inbox.
>>>>
>>>> On 1/7/26 03:13, Zeng Heng wrote:
>>>>> Some MPAM MSCs (like L2 MSC) shares the same power domain with its
>>>>> associated CPUs. Therefore, in scenarios where only partial cores power
>>>>> up, the MSCs belonging to the un-powered cores don't need and should
>>>>> not
>>>>> be accessed, otherwise bus-access fault would occur.
>>>>
>>>> The MPAM driver intentionally to waits until all MSCs have been
>>>> discovered before allowing MPAM to be used so that it can check the
>>>> properties of all the MSC and determine the configuration based on full
>>>> knowledge. Once a CPU affine with each MSC has been enabled then MPAM
>>>> will be enabled and usable.
>>>>
>>>> Suppose we weren't to access all MSCs in an asymmetric configuration.
>>>> E.g. if different L2 had different lengths of cache portion bit maps and
>>>> MPAM was enabled with only the CPUs with the same L2 then the driver
>>>> wouldn't know and we'd end up with a bad configuration which would
>>>> become a problem when the other CPUs are eventually turned on.
>>>>
>>>> Hence, I think we should retain the restriction that MPAM is only
>>>> enabled once all MSC are probed. Is this a particularly onerous
>>>> resctriction for you?
>>>>
>>>
>>> I have no objection to the restriction that "MPAM is only enabled once
>>> all MSC are probed." This constraint ensures the driver has complete
>>> knowledge of all Memory System Components before establishing the
>>> configuration.
>>>
>>>
>>> However, this patch is specifically designed to address CPU core
>>> isolation scenarios (Such as adding the 'isolcpus=xx' kernel command
>>> line parameter).
> 
> In the isolation scenario are you for some cpus, enabling MPAM, using
> those cpus but not taking into account the parameters of the associated MSC?

In the CPU core isolation scenario, the CPU affinity information of MSC
must be reported. In fact, ACPI MPAM table has already designed a
mechanism for reporting the affinity information of each MSC instance.

Through the "Hardware ID of linked device" and "Instance ID of linked
device" fields, the container and container ID to which the MSC belongs
are specified respectively, thereby obtaining the MSC affinity
information.

The kernel is responsible for parsing this information and determines
which MSCs should be initialized based on the currently online CPUs.

> 
>>>
>>> The patch allows the MPAM driver to successfully complete the
>>> initialization of online MSCs even when the system is booted with
>>> certain cores isolated or disabled. The patch ensures that MPAM
>>> initialization is decoupled from the requirement that all CPUs must be
>>> online during the probing phase.
>>>
>>> CPU core isolation is indeed a common production scenario. This
>>> functionality requires the kernel to enable functionalities in the
>>> presence of faulty cores (which cannot be recovered through cold boot).
>>> This ensures system reliability and availability on multi-core
>>> processors where single-core faults.
>>>
>>> Without this patch would prevent MPAM from initialization under CPU core
>>> isolation scenarios. Apologies for not mentioning in the patch: we can
>>> verify the functionality by adding 'maxcpus=1' to the boot parameters.
> 
> For 'maxcpus=1' I think the correct behaviour is to not enable MPAM as
> the other CPUs can then be turned on afterwards. E.g by
> echo 1 > /sys/devices/system/cpu/cpuX/online
> 
> For faulty cores how would you ensure they are never turned on?
> 

The maxcpus=1 is merely an extreme simulation scenario. In production
environments, detected faulty cores have already been disabled by the
BIOS firmware and cannot be brought online again.


Thanks,
Zeng Heng