From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout09.his.huawei.com (canpmsgout09.his.huawei.com [113.46.200.224]) (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 9C78418A6A7 for ; Mon, 2 Feb 2026 12:47:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.224 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770036425; cv=none; b=TKKx7YCIwUni3X90Vual+J07sWgZv7cz6GoFZvQ3cpzHdDhCQGjh2SJslmiW/WIEt9iuVqHmrsxHVaN5pmYNW+axNAOl/hYO6h+qsEiE8/lJi5zn4B8b6ZeLY0cBeBfp/9D5vhKZGcdJmxljcdxscZqyaOJhU2rATsRWDd5hf3I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770036425; c=relaxed/simple; bh=gA9CUuWm5FB8u9RGx6oazeVDbmCMdQ2G43sYZbNzVKk=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=HYUrupIh4PrFBb+PQHHvggcXe6s5HdKwHls6lDVnB9geYt8zdRWcsiUjqD8/esMdyNLtjB5ohugd0SmVYU6rEU/3A/8HPfBAZecGOhOZhfPUTKUQjn90+dwIDQH1NAfbIo5chaYroLY2vp6Kzu9lYMWP7IQnaKL2oSk8268N++Y= 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=ZFqR6FK+; arc=none smtp.client-ip=113.46.200.224 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="ZFqR6FK+" dkim-signature: v=1; a=rsa-sha256; d=h-partners.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=CiBipwHjVPQ027kPwEIVCyv66XJxQ3sOgAQeBPFQvD0=; b=ZFqR6FK+4rXlpy5Iak19leGTgtluE2uhV9oXqniA1MlkpsLx4lGmQCFVdQedT4wKjl1idJ7We 8YxjmVnha83kN6IIo/wGjm2vrifjf1eXFQP1IqG1kVRN/wKVPRGu2eIHp7MlF/JpNgOOxXuBtQR J12rbFdMw1d6/i4hSAZVZtQ= Received: from mail.maildlp.com (unknown [172.19.162.92]) by canpmsgout09.his.huawei.com (SkyGuard) with ESMTPS id 4f4R8b6KyFz1cyPZ; Mon, 2 Feb 2026 20:42:23 +0800 (CST) Received: from kwepemf100008.china.huawei.com (unknown [7.202.181.222]) by mail.maildlp.com (Postfix) with ESMTPS id 9B79040568; Mon, 2 Feb 2026 20:46:56 +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; Mon, 2 Feb 2026 20:46:55 +0800 Message-ID: Date: Mon, 2 Feb 2026 20:46:55 +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 To: Ben Horgan , , , CC: , , Jonathan Cameron References: <20260107031336.3599175-1-zengheng4@huawei.com> <29a433ac-3247-f3f1-323e-70187c76f46a@huawei.com> From: Zeng Heng In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemf100008.china.huawei.com (7.202.181.222) 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