From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) (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 103FE2E5439 for ; Fri, 5 Dec 2025 13:08:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.168.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764940134; cv=none; b=GFSwj3ggMYDYzipLsRXdkBrn4xMSZpml30LnUaAYlWQL9JUd5QrxEaKJxowi8G6ghtNkDUhkPDcfaSNjCYH+S6fEyEVshkzdjgDPXMicEMyphU2qMUEb/YoUK0q4nf4OsUs6qyGlR7kJF2iix3aFi+P1sjuhxq5JprLvATRUKJw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764940134; c=relaxed/simple; bh=6K2EjrQGBJiPzI1YiE11ab9VCMGxL1xQJ8x2aOjHCpU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=rCfj6sIFVfl6NHvMrBoMEnhtkfwZd+Z8ZQfLeRvrTzrEYb41FJMSj/CE8f2NTvlOGCyok++cAAYzierVwCGXaZ4o3bfoVB7b+C5qcrEG+1n6uS0eebjtxJ8YMWE7K++QahmBe3A9aWfNHXlw7Sv4Y6fSurr9c4OrRFT30cvqPtI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=jdtk4Ma6; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=S2m12MNI; arc=none smtp.client-ip=205.220.168.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="jdtk4Ma6"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="S2m12MNI" Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 5B5CrK58234666 for ; Fri, 5 Dec 2025 13:08:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=qcppdkim1; bh=aJNZlqMyVpKqCVauRzrnOtmM cjDznFVaeApZ23rdtJQ=; b=jdtk4Ma60YUKV/uVdaOGpuNZS0SdVyoAHNOogZnA b4m1hBNXgYSzExerCqlvPC49B5Ehr7YfhzMwiNSfQGgfHq99ygdWQvkCjQU4hGkv wEoZr0HO4F7efWkhzHWcmdKAVIp0d9DOUx75lH8YDfTD5oYKRvoa6WGlfRGY8ZAD j+CwXqCWelgHlSM1D5TLlv+IRTyLrOrJeH+7oyUSAXC/U0dwzfmt4m2nXBnuMFBX a0R7Fit8RGqOX/oR3wQD5cfaPT2gN5wyKaWCp9leTYOwQrs5GnsxJa5KjORwhr81 0QqvhzQPirqFY6hORkSZwm+lnfceTlbwEKjuuGN8jlA+HQ== Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4auys7g18n-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 05 Dec 2025 13:08:43 +0000 (GMT) Received: by mail-ua1-f70.google.com with SMTP id a1e0cc1a2514c-937192200c7so3074115241.1 for ; Fri, 05 Dec 2025 05:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1764940122; x=1765544922; darn=vger.kernel.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=aJNZlqMyVpKqCVauRzrnOtmMcjDznFVaeApZ23rdtJQ=; b=S2m12MNI4pth3GkHSlKHiP4FbJ332Xt89fC3z9zhVy7cIyMhLmlANWGYgcJTRDTXwL EZtohHXf6kd0MpdnBo987J3CPVTfEwYLDuDCktkh8uyMozPQUKPqkIfFrMTKo8WYNq00 +O+64KDNOCduEDzJLy0Y2tqPml+//eLw3m+LZ6lEEgweO85h5NQdeBMvVFpfgQKljVHp QdDT8xSIMDLpO7La/pYusssE/7yGDQJmR4AkZ3QUVvM91/otCX1yVZwg0c5BKroCsalo JXjdP4qEvTmT2oa07DiY8SDc1gvG3DbCmAIRTXqslDo76I7OeBEJY0NGvxF8kvBhfuG3 6JWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764940122; x=1765544922; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=aJNZlqMyVpKqCVauRzrnOtmMcjDznFVaeApZ23rdtJQ=; b=YvcyQbcDt/qVWNvG8V8WWhxEbqZU1BE+z5916p8UNPxdxXOSs27i88WpKjlLV8CnWP nwVAdIaxhxwaqfHkfc7KwvmxLfU24ADuQKJs+2fAbffhmuUBZZdO0URj1NdgDQVc6nNd MurZAPI7F763/XgOBx4eEY1LICUGKkZhkVQrFrs9fOfQjPfVszYMWGlCXeEz7KqpfSQC VtlBcymN/ixfiMUQDqGJeYeq3mk+gEAvo16VZIx+du6ifOoggeBMrgEgsELWqL1WfYFc KvSGEOulDgyP2ElwsN+t8XHE3L1ZKEdP+SiyobaqhDt4xODw4+4Q0khDoXkxyjOW3d9e geFQ== X-Forwarded-Encrypted: i=1; AJvYcCV4VxKgefUpi8C+EIY5Xe7dCfE4vyu6OBRsNk5FRCowMPJ/+kKLDVXj/WBK/2k18jxo9+/bPi1JcLRnPvU=@vger.kernel.org X-Gm-Message-State: AOJu0Yyzm5vFPWaqwWX/QRNvEEnRGyTkahpimcdc/jmpoOnMt+5/pV2P kjgSyDANTYZjLFZ/RsT3y8f1QnR9mi7GX5VWq9KbC13p85VBA2Dbvy7b2ptZEBw4PQjRcmAZzdW tt4lnWaE2dhTp9tkBBHXM8dwhcpHjid7xHeX/LGbpLLtOxxJFcwpLRkrrMA70xOcOW+w= X-Gm-Gg: ASbGncsk2ZZUEw01K9whR4lc8hLtbxtCVC0qod83Ik97CEgNoKRrerTg/yvGMtrDJzw oMl479MR2JAeUgSYFKGwayYYIaJACrECnrTpog19KqeqT4JO3kfdZkBRlTksGu3E5jrboNYVMr5 bqO84e++IPhdK1CRNQpsFOqU2JM0lsZe5gYmojJWpelgWvf2azbmz7u3RaTco1f8yWny+U6TGJP 5Uk8nVf7Wk1QDUsCJ9SDpHDNvi7yLF9+S3zBFtY4Sdy56O/M4TQuM6Ad/mXe1SlUhYJfxcX6XGi belP7Pc6Deuvcqmtm5NRGEiHpZR5Yhs4wzwOvI4P6svHlVktB4iJwNyjxve2FYNq+X0PlJuPHz6 s0nVmYV2PIybe3dlBNdBcsbfY X-Received: by 2002:a05:6102:5818:b0:5e1:866c:4f7c with SMTP id ada2fe7eead31-5e48e3d3c32mr3751056137.39.1764940122612; Fri, 05 Dec 2025 05:08:42 -0800 (PST) X-Google-Smtp-Source: AGHT+IHoVFLXE/I17RgN98+gHQViOk7KSVZOb5/MXqt1hrIeWuM9v9uKcV9QR6B6Q6gd7CA/qJwGVQ== X-Received: by 2002:a05:6102:5818:b0:5e1:866c:4f7c with SMTP id ada2fe7eead31-5e48e3d3c32mr3751005137.39.1764940122130; Fri, 05 Dec 2025 05:08:42 -0800 (PST) Received: from localhost ([2a01:4b00:b703:c200:1ac0:4dff:fe39:5426]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-47930c76edcsm82740975e9.11.2025.12.05.05.08.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Dec 2025 05:08:41 -0800 (PST) From: Punit Agrawal To: James Morse Cc: Punit Agrawal , Ben Horgan , amitsinght@marvell.com, baisheng.gao@unisoc.com, baolin.wang@linux.alibaba.com, bobo.shaobowang@huawei.com, carl@os.amperecomputing.com, catalin.marinas@arm.com, dakr@kernel.org, dave.martin@arm.com, david@redhat.com, dfustini@baylibre.com, fenghuay@nvidia.com, gregkh@linuxfoundation.org, gshan@redhat.com, guohanjun@huawei.com, jeremy.linton@arm.com, jonathan.cameron@huawei.com, kobak@nvidia.com, lcherian@marvell.com, lenb@kernel.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, lpieralisi@kernel.org, peternewman@google.com, quic_jiles@quicinc.com, rafael@kernel.org, robh@kernel.org, rohit.mathew@arm.com, scott@os.amperecomputing.com, sdonthineni@nvidia.com, sudeep.holla@arm.com, tan.shaopeng@fujitsu.com, will@kernel.org, xhao@linux.alibaba.com, reinette.chatre@intel.com Subject: Re: [PATCH v6 00/34] arm_mpam: Add basic mpam driver In-Reply-To: <642767c9-f926-490a-83a1-160978c37553@arm.com> (James Morse's message of "Wed, 3 Dec 2025 17:34:37 +0000") References: <20251119122305.302149-1-ben.horgan@arm.com> <877bvfa23i.fsf@stealth> <87sedrlsjk.fsf@stealth> <642767c9-f926-490a-83a1-160978c37553@arm.com> Date: Fri, 05 Dec 2025 13:08:40 +0000 Message-ID: <871pl9krdz.fsf@stealth> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMjA1MDA5MyBTYWx0ZWRfX+Lx8Y1Eanh6Q 4VPtD66HW8knfxznWR3Zu8IJCmCBkWHxKgVEXaB7M5yPpsuJwXIRljlLGluA2OzI0dWRMT7prJ1 uK8GlmnIeLoE4qHWkaDIh5vDsym41T0WGyQArXsSBGBrxoV8W7WLdzboWsCDFAzPb2o1/vSPDg0 gKyAolTPSFHygMyWG1Z8eoD8aaCTplYzyiph4UC525X+wZFRsqjuyb5dlImGrYlVY5SpqCqaD3J h1lWFRlUKxPxjfeaJyy6jgRrSjdHMniiYdNoadunPvvVVNHoiHNfVAp0bNyRboz+FG0zhURRRSf ZWcU2c6LX41EDnQIDnZ0EKKyI0EQlENgy4FE4cYK5HUPaTRuURYNHTBbGEWTIZPV0LmWdxoZqvI TGAlX7vmko36p7ESxd875DTbM8Vkcg== X-Proofpoint-ORIG-GUID: n4pZEnyQXdE0FzmWGvCuGRdqTSxVHohm X-Proofpoint-GUID: n4pZEnyQXdE0FzmWGvCuGRdqTSxVHohm X-Authority-Analysis: v=2.4 cv=GtVPO01C c=1 sm=1 tr=0 ts=6932d95b cx=c_pps a=R6oCqFB+Yf/t2GF8e0/dFg==:117 a=xqWC_Br6kY4A:10 a=wP3pNCr1ah4A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=7CQSdrXTAAAA:8 a=aZ4QdqtX2bFftAu5rtMA:9 a=TD8TdBvy0hsOASGTdmB-:22 a=a-qgeE7W1pNrGK8U0ZQC:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-12-05_04,2025-12-04_04,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 bulkscore=0 adultscore=0 suspectscore=0 impostorscore=0 clxscore=1015 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2510240001 definitions=main-2512050093 James Morse writes: > Hi Punit, > > On 03/12/2025 11:21, Punit Agrawal wrote: >> Ben Horgan writes: >>> On 11/24/25 15:21, Punit Agrawal wrote: >>>> Although a little late to the party, > > There was a party?! > > >>>> I've managed to throw together >>>> enough firmware to describe the MPAM hardware and take this set (more >>>> specifically mpam/snapshot/v6.18-rc4-v5 branch from James' repository) >>>> for a spin. Using the branch, the kernel is able to probe the hardware >>>> and discover the advertised features. Yay! We are in business. >>> >>> Thanks for giving it a go. :) >>> >>>> >>>> Having said that, there are a few quirks of the platform that run into >>>> issues with later patches in the branch. > > So something in the resctrl support code is causing this. > Any idea which patch causes this to happen? > > There are a load of pr_debug() in the picking logic, if you enable DYNDEBUG and add: > | dyndbg="file mpam_resctrl.c +pl" > > to the commandline, you should get some snotty messages about what non-Xeon-like property > your platform has. Thanks - I've got this enabled. The platform looks very different to a Xeon. One notable difference being a shared L2. Hence all the MSCs attached there. >>>> The platform has MSCs attached >>>> to shared L2 caches which are being skipped during later stages of >>>> initialisation. IIUC, the L2 MSCs' limitations stems from the >>>> assumptions in the resctrl interface. >>> >>> What in particualar is being skipped? > >> The registration of the discovered MSCs with resctrl and subsequent >> exposing it to the user. > > resctrl's 'L2' support is limited to the CPOR bitmap. > If you have controls, there is no resctrl 'event' that can exposed them. > (the problem being they all have 'L3' in the name!) >>>> I was wondering if there are any patches available to relax these >>>> limitations? > Knowing which property it is will help - but some of these things are checked > to match resctrl's ABI. They can't necessarily be relaxed without breaking > user-space. This platform has portion, capacity and priority partitioning, as well as memory bandwidth and cache storage monitoring. The MPAM code seems to correctly parse the properties. But as you point out, the resctrl 'L2' support doesn't have anything other than CPOR bitmap yet. Have you looked at what's needed to extend resctrl to support some of the others? > Others are sanity checks, e.g. all CPUs are represented. This is to avoid tasks > that run on cpu-9 escaping the resctrl controls. Platforms that did this may as > well not bother with resctrl at all. > > >>>> I can give them a try. Or do these need to be put together >>>> from the ground up? Any pointers greatly appreciated. >>> >>> There are some extra things added in the extras branch [1] e.g. cache >>> maximum usage controls (cmax). However, lots of possible things are >>> still missing e.g. any monitors on L2. If it doesn't fit with the >>> topology expected by resctrl then it is unlikely to have been considered >>> yet. >> >> Thanks for the pointer. I'll give the snapshot+extras branch[1] a try. >> >> The platform does have both controls and monitors attached to L2. If >> this isn't being looked at, I can try and put something together. Thanks >> for confirming that the limitation is likely due to resctrl. > > My view on 'extra' counters is to try and expose them via perf, as this would also > allow platform specific counters. I worry that if we start adding 'easy' ones like > l2_mbm_total to resctrl, someone will want > left_hand_side_of_soc_mbm_total. I wouldn't club L2 in the same category as 'left_hand_side_of_soc'. You call it 'easy' for a reason. L2 is pretty well understood and resctrl already exposes an interface for it. I would avoid creating a new interface for users. For some of the other boundaries, things like 'left_hand_side_of_soc' I wonder if firmware provided topology (e.g., PPTT, SRAT, etc) could be used to make even this work.