From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout12.his.huawei.com (canpmsgout12.his.huawei.com [113.46.200.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C004D285C91 for ; Tue, 3 Feb 2026 09:22:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.227 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770110555; cv=none; b=SwOHHrIa1ShguNpep41LrWz4IDIlCHPPNbB3Irgw2yDm6XtZrnGcyDGJ/DPfFAo9qInp/G8j00pERJxrZO63FZovzYCJH9vwXDwqXzBemS2TWr4liL6gWhOusKG7FQDJGf3ussLvwRcvJTke6EjtHTKdZgiZ+vG12AfvSmvNTN0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770110555; c=relaxed/simple; bh=wONuc0kheX+vOlT7LWbPiuB4Fu0KryIm+iz4m8HJ4ow=; h=Message-ID:Date:MIME-Version:Subject:From:To:CC:References: In-Reply-To:Content-Type; b=EGu4MQ95Kol5GQAdpOW7jVVRsW5DFtGvfyiixC4wG5ywNQ8jPnSrDSBwaDEC8t+YXHITC9HyFoc7jZn0krLrz3NlA088qLSGMbSvtz3mED357fepshamqNnhCLQ8CVbwNvg8IgWM+UJTVeQg2Hj515yq5bBs9vhJuKNkumG5vCI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=h-partners.com; dkim=pass (1024-bit key) header.d=h-partners.com header.i=@h-partners.com header.b=PscFZ6vP; arc=none smtp.client-ip=113.46.200.227 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=h-partners.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=h-partners.com header.i=@h-partners.com header.b="PscFZ6vP" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=j5RWDxfXyTQnF1mKNAM7/o/TnBOfyVlCsaTBmrHzJ1E=; b=PscFZ6vPSAi1OIWwU0LDrR6VqoVzqcFxQscMpQkSiQkScz50zuWAL1FU3UwIDbaB8i9jMpQBz e4+MfWCHHxdzT6OPTGA7Wj/0PIBj3rEnBIXg95RtuytVsmDEmwDoHK+G8SD6YgbhEQHnW6KFZve ac/AVRT2XOo4hjR70IK5kSY= Received: from mail.maildlp.com (unknown [172.19.163.214]) by canpmsgout12.his.huawei.com (SkyGuard) with ESMTPS id 4f4yb22c4FznTV6; Tue, 3 Feb 2026 17:18:38 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id BD0114056C; Tue, 3 Feb 2026 17:22:28 +0800 (CST) Received: from [10.174.178.24] (10.174.178.24) by kwepemf100008.china.huawei.com (7.202.181.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Tue, 3 Feb 2026 17:22:25 +0800 Message-ID: <196146e6-6366-b09b-c367-facf10af6b9b@huawei.com> Date: Tue, 3 Feb 2026 17:22:24 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH] arm64/mpam: Support partial-core boot for MPAM Content-Language: en-US From: Zeng Heng To: Ben Horgan , , , CC: , , Jonathan Cameron References: <20260107031336.3599175-1-zengheng4@huawei.com> <29a433ac-3247-f3f1-323e-70187c76f46a@huawei.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems100001.china.huawei.com (7.221.188.238) To kwepemf100008.china.huawei.com (7.202.181.222) On 2026/2/2 20:46, Zeng Heng wrote: > 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. > > Even the faulty cores or offline CPUs are turned on, the patch does not affect the automatic recovery and bring-up of MPAM MSCs. Adding 'maxcpus=1' to the boot parameters, and testing with the patch applied is as follows: # mount -t resctrl l resctrl /sys/fs/resctrl/ # cat /sys/fs/resctrl/schemata L2:4=ff L3:1=1ffff # echo 1 > /sys/devices/system/cpu/cpu2/online # cat /sys/fs/resctrl/schemata L2:4=ff;7=ff L3:1=1ffff # echo 1 > /sys/devices/system/cpu/cpu16/online # cat /sys/fs/resctrl/schemata L2:4=ff;7=ff;29=ff L3:1=1ffff;26=1ffff # echo 0 > /sys/devices/system/cpu/cpu16/online # cat /sys/fs/resctrl/schemata L2:4=ff;7=ff L3:1=1ffff # echo 0 > /sys/devices/system/cpu/cpu2/online # cat /sys/fs/resctrl/schemata L2:4=ff L3:1=1ffff Best Regards, Zeng Heng