From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.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 5B3203909A9 for ; Fri, 10 Jul 2026 19:58:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783713522; cv=none; b=UB6leCdLykiblzX4KwNu0DsgxaatZSWiUhl4hNb+hZNReML1mcoa1yURd4CTccuWxrFA/usaXVWQg+6qWzQVd2I5InOJBqSd3xjngH4SCULUSGsa4aE1drPxqV4+XVzbrxCLYbPe7lNSP08F5XdhqVXYfbKicrGvZOgVUDXbqng= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783713522; c=relaxed/simple; bh=Sgb3V1zLwDAFN3q6+NHM1Zrxge6RiREC9mw7dCK7Aro=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QukiNzvjUxJDHgo6/ZDSkLHMWQ2BWCS8e833tR4T7q4jwXplKG3OesRoiA4RuMFBRU+o6ilM55gBkcA4zG2PRxn3tIkRS4rKUCcbHKGCVmAS6XZy2jPhCxyODd6d/NExPb/LZZt4VqFXR5lu4RvlBumOcyvkFBl3SlyB5w/VE1M= 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=nzQCYrK8; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=Loi608oE; arc=none smtp.client-ip=205.220.180.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="nzQCYrK8"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="Loi608oE" Received: from pps.filterd (m0279870.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66AH5Vf21408307 for ; Fri, 10 Jul 2026 19:58:38 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= 5xSK4+lHSvlK826QqeBR8DeMUlV8JNVRsDYih4vnYtI=; b=nzQCYrK8LP9hgzSZ XKuUB3ncjjQnXD4N38nJrEftUMXMF0IQ+XdM46Xz2gQpm4dp28u8FLRZURK2DhkA ozbqSKlJ8TkZbg2Wbr6iDqHMI+W00NjplfUoeYl8tH/ibRuomGfqMBlLgNBxNxQN w3Nrerwis03C6FAXBjwWYhrNRs8tGRW/VXAlNOYZeJ4BIjQO50+NAOMJ16qJcKFO +HSsq9LAzKbNfPkSY2zRwBWq68N0M/g98TntGBmrzC/1CEASt+Q9KYuBu4FnZEGo AaMhNdhtpePoXGNrhzRre+V+qSMPp2SFNv5N9W4l+GqOhSGlfrC8/HlXPiuTSWXr QnctfA== Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fax5fa8xv-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 10 Jul 2026 19:58:38 +0000 (GMT) Received: by mail-pg1-f197.google.com with SMTP id 41be03b00d2f7-cab048cdb3eso159465a12.0 for ; Fri, 10 Jul 2026 12:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1783713517; x=1784318317; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:organization :references:in-reply-to:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to:content-type; bh=5xSK4+lHSvlK826QqeBR8DeMUlV8JNVRsDYih4vnYtI=; b=Loi608oEXCkp8RL8jkktpKPhIPb36WKYtFtVQt55oH6rlFOvfQTMRQlGiPmVjArGZ/ TCpgjHxBlCAOTRoqsY4c+MSfFoJk60NjS+/Dv/oINSTaoO6zEXx9hrIq9zfzLaehDEDm /VImKxmY4xgasMX59blLIo/29hAnI9Q2XUbQpOKnQl8f3cCgeSIOpP6XHbVoSgyIRk6x e5sYpmXxeoWQ7PN1nwjfo84OBT3XQjcRAmdx8oFsGoEJ7/s20xcryZnYQ2bKIw9ncTYH rmgdN7F5kfWrgJrp9lAZ+dOEBZ4A/XCh5AXoBgHlHgZOSq9u/o7lqkiclDxMyx8zd/y3 xjow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783713517; x=1784318317; h=content-transfer-encoding:content-type:mime-version:organization :references:in-reply-to:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=5xSK4+lHSvlK826QqeBR8DeMUlV8JNVRsDYih4vnYtI=; b=Yy1/ydWocYv25PrmgEW7GM64ShZlz/C/gHB5tU7FB8MGmsONYGvnHmWxBJTkgtaEp5 QyfVPBdJJx2KA70w5xqkdnH1CzqvRTNMb+LQzaFiNN4hEi0uteMBHJXUYTQ4ye1x8SIR jY07d9tCbjTu0DFTuLUSxz89anL2eLit/b1RVSMlijYR3C33BZBJ17j0ZodJ6dpppDDt 7XVPQeCevrJD7fRRZkdblQZ3V/SSj34PoR5SkQXBkkm6LALB6L+bOAPVRAoM7NdbPgBI iXwbkqW6PoZNPItJ6U95P3Rw2szldG44fr/egVNtSVBQHRpvyYrymwwWplgoDtR0MI5c tJ7A== X-Forwarded-Encrypted: i=1; AHgh+RoiKLRrlXWy4LZnqmMNxEdSDa6zL94I7mysC/9QMZZLQkRoY8Xrw9axl2DfrRs/p6q8Ae7+qDVF6vbvU/Q=@vger.kernel.org X-Gm-Message-State: AOJu0YzBOrrkJ5zcr7ok4jx0hGuev8YKYBBILcZqnwkOB+PmvSHYQn4P MXtN9oKWhhBaB9bxVcCyGd5JLw3IqHUXI7yl2iwPc8m3ltypm2DM2IIiaM1cQawxFtRpXahH7xB /iOspJUEy3zHVAnalyF/m7yUI7FLV4Qi3qAQtBjv1EX0FHW/k3HYPrqcmIh8MvDL/iBI= X-Gm-Gg: AfdE7clCitWws7VtIG1RJNWrZE8p+q/Dt4Ibq9FiAnDlek7S6n9OcKCs1iUG+yttrq3 CTbGThHzqR6ITmEGltg83ZRPJe+7ShlNTHJ45Z2pMnn7HsyRFWPyUdjgE0OB2q/mpb1uJOOUKjg qG3dBh294Aj6tbhODiTZQRYgo/PtgUUVTFjzaFUYIbsnZ6BNgxqaNq2073dQfg+WJyQoPUEW2q/ 2vj1ch7enlakNza7v4UIdwfGGbfHC9Ck8gg7oqgIxFAskjuHFhCIuTkuw0vwPz8A0qqnxe4+3tw bkvu2nyAuot5mQ6s6Z6MOtl9dv+U7NNJcVO1eEgKaCCck5PMC4hD8zQy9vGrcMzth4CHtcxEaaj hF0ze4C4XsQutnjVScJksX3nAwRyL30z7kcPF X-Received: by 2002:a05:6a20:4328:b0:3c1:a0c:ab85 with SMTP id adf61e73a8af0-3c111095f37mr361769637.76.1783713517192; Fri, 10 Jul 2026 12:58:37 -0700 (PDT) X-Received: by 2002:a05:6a20:4328:b0:3c1:a0c:ab85 with SMTP id adf61e73a8af0-3c111095f37mr361729637.76.1783713516726; Fri, 10 Jul 2026 12:58:36 -0700 (PDT) Received: from localhost ([50.35.46.84]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-313b3206aaasm8187103eec.13.2026.07.10.12.58.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Jul 2026 12:58:36 -0700 (PDT) Date: Fri, 10 Jul 2026 12:58:32 -0700 From: Jonathan Cameron To: Andre Przywara Cc: Lorenzo Pieralisi , Hanjun Guo , Sudeep Holla , Catalin Marinas , Will Deacon , "Rafael J . Wysocki" , Len Brown , James Morse , Ben Horgan , Reinette Chatre , Fenghua Yu , Jonathan Cameron , Srivathsa L Rao , Ganapatrao Kulkarni , Trilok Soni , Srinivas Ramana , Niyas Sait , linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 14/16] arm_mpam: add MPAM-Fb MSC firmware access support Message-ID: <20260710125832.00003be9@oss.qualcomm.com> In-Reply-To: <20260710144520.917375-15-andre.przywara@arm.com> References: <20260710144520.917375-1-andre.przywara@arm.com> <20260710144520.917375-15-andre.przywara@arm.com> Organization: Qualcomm X-Mailer: Claws Mail 4.4.0 (GTK 3.24.51; x86_64-w64-mingw32) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Authority-Analysis: v=2.4 cv=Ab2B2XXG c=1 sm=1 tr=0 ts=6a514eee cx=c_pps a=rz3CxIlbcmazkYymdCej/Q==:117 a=qC1CW/w66vtJz1P9yTJxNA==:17 a=kj9zAlcOel0A:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=gowsoOTTUOVcmtlkKump:22 a=7CQSdrXTAAAA:8 a=BKSArZ9tf1QpHAMEYIoA:9 a=CjuIK1q_8ugA:10 a=bFCP_H2QrGi7Okbo017w:22 a=a-qgeE7W1pNrGK8U0ZQC:22 X-Proofpoint-ORIG-GUID: Qks6hm12B4kWPAgv5sKMeaUssV-jEIiz X-Proofpoint-GUID: Qks6hm12B4kWPAgv5sKMeaUssV-jEIiz X-Proofpoint-Spam-Info: AW1haW4tMjYwNzEwMDIwMCBTYWx0ZWRfXxxWmxUjIjpy5 0lqSJFBpfJyrFkEDCYMSm0DEwlr5F+PgYCKL9Z4LMiHkM3wvbSvmZZ/ZcJsTSR44MWh9Kk8P1db OUSdpYJsQ8SJoTghUufbgZRavKzRoTw= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzEwMDIwMCBTYWx0ZWRfX5H5W/HQeC3R2 +dRMaFBTP82ofsUHXXM6DT8dIqnMBYr6pfgb7TIzw0CrL29EljJs4pUdsiQGDBdLdOeQN76K7th 9LiR6QRtijyZ8oQiiICqektXPktTP6o4YoL+iQFkt8asKFdUzTHtcdPuWFjvRRQYfaN6hUBty3B 7C15F3dNQRziMH3+f6mnYWsnNKpxJGhsOd1tVQ/hQuVg7ev2pnAdsYKnADp4uqlu4+1eeZZZGCa NdXQadKQ7Y+v01s72nMETHLs4kPMmSiu30m8iyyR3kJDfE0bC5CYBE6Zuj745ALoULkxEDtF4aD SdcTikaMpuwW/iG2xOa3YXEzJ5zUbDkBQ0tL3Evz7rmX5csV2v0Zo/Ri/9V4KTEiRYTz+XoiHDS bWC6hEF5PceEH9jfzkfbBCy7wXemh6abYD8E0cnxm9VtxcdvqhRSF0kKYK4h5iUjr3npcTbkXBb 8Se1asGWPJFrJs+bB6Q== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-07-10_05,2026-07-10_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 clxscore=1015 malwarescore=0 phishscore=0 bulkscore=0 suspectscore=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607100200 On Fri, 10 Jul 2026 16:45:18 +0200 Andre Przywara wrote: > The Arm MPAM Firmware-backed (Fb) Profile document[1] describes an > alternative way of accessing the "Memory System Components" (MSC) in an > MPAM enabled system. Blank line for consistency on paragraph breaks. > Normally the MSCs are MMIO mapped, but in some implementations this Hmm. Not sure what normal is in this case ;) Maybe make it something like In systems supported before this patch the MSCs are MMIO mapped, > might not be possible (MSC located outside of the local socket, MSC > mapped secure-only) or desirable (direct MMIO access too slow or needs > to be mediated through a control processor). MPAM-fb standardises a > protocol to abstract MSC accesses, building on the SCMI protocol. > > Add functions that do an MSC read or write access by redirecting the > request through a firmware interface. For now this done via an ACPI > PCC shared memory and mailbox combination. > > Since the protocol used is only a small subset of the full SCMI spec, > and the SCMI protocol has no full ACPI support anyway, open-code the > SCMI message generation and handshake, for just the fields we need. > > [1] https://developer.arm.com/documentation/den0144/latest > > Signed-off-by: Andre Przywara Hi Andre, Various things inline. Thanks, Jonathan ... > diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c > index ca73029654b6..4d3e642486d4 100644 > --- a/drivers/resctrl/mpam_devices.c > +++ b/drivers/resctrl/mpam_devices.c > @@ -1133,7 +1139,8 @@ static int mpam_msc_read_mbwu_l(struct mpam_msc *msc, u64 *res) > > mpam_mon_sel_lock_held(msc); > > - WARN_ON_ONCE((MSMON_MBWU_L + sizeof(u64)) > msc->mapped_hwpage_sz); > + if (msc->iface == MPAM_IFACE_MMIO) > + WARN_ON_ONCE((MSMON_MBWU_L + sizeof(u64)) > msc->mapped_hwpage_sz); > WARN_ON_ONCE(!cpumask_test_cpu(smp_processor_id(), &msc->accessibility)); > > ret = __mpam_read_reg(msc, MSMON_MBWU_L + 4, &mbwu_l_high2); > @@ -1481,9 +1488,15 @@ static int _msmon_read(struct mpam_component *comp, struct mon_read *arg) > srcu_read_lock_held(&mpam_srcu)) { > arg->ris = ris; > > - err = smp_call_function_any(&msc->accessibility, > - __ris_msmon_read, arg, > - true); > + if (msc->iface == MPAM_IFACE_MMIO) { > + err = smp_call_function_any(&msc->accessibility, > + __ris_msmon_read, > + arg, true); > + } else { > + __ris_msmon_read(arg); > + err = 0; > + } > + > if (!err && arg->err) > err = arg->err; FWIW The arg->err check here seems pointless if (!err) err = arg->err; is at most going to set a 0 to 0. Maybe lift this into the if else as it should end up simpler in the else. if (msc->iface == MPAM_IFACE_MMIO) { err = smp_call_function_any(&msc->accessibility, __ris_msmon_read, arg, true); if (!err) err = arg->err; } else { __ris_msmon_read(arg); err = arg->err; } if (err) any_err = err; ... > diff --git a/drivers/resctrl/mpam_fb.c b/drivers/resctrl/mpam_fb.c > new file mode 100644 > index 000000000000..7d7409910f28 > --- /dev/null > +++ b/drivers/resctrl/mpam_fb.c > @@ -0,0 +1,208 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// Copyright (C) 2024 Arm Ltd. Really? sat on this for 2 years? ;) Given it's changing during this posting I'd at least include this year in the range. > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include Scrub these for things used in this patch. Maybe others will be needed after later patches. Not seeing any of_ stuff in here for instance. > +#include > +#include > +#include > +#include > +#include > +#include > +struct mpam_fb_access_payload { > + u32 msc_id; > + u32 flags; > + u32 reg_offset; > + u32 value; > +} __packed; There are only a few of these in spec, and whilst they share the same layout for fields they define (not all same length), I'd define separate structures for each of the message types. Added bonus being that... > + > +#define PCC_CHAN_FLAGS_IRQ BIT(0) > +#define MPAM_VERSION_MSG_SIZE (PCC_TYPE3_MSG_PAYLOAD_OFS) > +#define MPAM_READ_MSG_SIZE (PCC_TYPE3_MSG_PAYLOAD_OFS + 3 * sizeof(u32)) These would then become PCC_TYPE3_MSG_PAYLOAD_OFF + sizeof(mpam_fb_read_request_payload) or something self describing along those lines. > +#define MPAM_WRITE_MSG_SIZE (PCC_TYPE3_MSG_PAYLOAD_OFS + 4 * sizeof(u32)) > + > +static atomic_t mpam_fb_token = ATOMIC_INIT(0); > + > +static int mpam_fb_build_version_message(unsigned int token, > + void __iomem *msg_buf) > +{ > + struct acpi_pcct_ext_pcc_shared_memory *pcc_shmem = msg_buf; > + > + writel_relaxed(0, &pcc_shmem->flags); > + writel_relaxed(MPAM_VERSION_MSG_SIZE, &pcc_shmem->length); > + writel_relaxed(MPAM_PROTOCOL_VERSION | > + FIELD_PREP(MPAM_MSC_TOKEN_MASK, token) | > + FIELD_PREP(MPAM_MSC_PROT_ID_MASK, MPAM_FB_PROTOCOL_ID), > + &pcc_shmem->command); > + > + return MPAM_VERSION_MSG_SIZE; > +} > + > +static int mpam_fb_build_read_message(int msc_id, int reg, unsigned int token, > + void __iomem *msg_buf) > +{ > + struct acpi_pcct_ext_pcc_shared_memory *pcc_shmem = msg_buf; > + struct mpam_fb_access_payload *payload = msg_buf + sizeof(*pcc_shmem); > + > + writel_relaxed(0, &pcc_shmem->flags); > + writel_relaxed(MPAM_READ_MSG_SIZE, &pcc_shmem->length); > + writel_relaxed(MPAM_MSC_READ_CMD | > + FIELD_PREP(MPAM_MSC_TOKEN_MASK, token) | > + FIELD_PREP(MPAM_MSC_PROT_ID_MASK, MPAM_FB_PROTOCOL_ID), > + &pcc_shmem->command); > + > + writel_relaxed(msc_id, &payload->msc_id); > + writel_relaxed(0, &payload->flags); > + writel_relaxed(reg, &payload->reg_offset); > + > + return MPAM_READ_MSG_SIZE; > +} > + > +static int mpam_fb_send_request(struct mpam_pcc_chan *pcc_chan, u32 msc_id, > + u16 reg, u32 *result, int mpam_fb_command) > +{ > + unsigned int token = atomic_inc_return(&mpam_fb_token); > + struct acpi_pcct_ext_pcc_shared_memory *pcc_shmem; > + struct pcc_mbox_chan *chan; > + void __iomem *payload_ofs; > + u32 status; > + int ret; > + > + if (!pcc_chan) Is this defense needed? Feels like the sort of thing that is so fatal if you get to call send_request() that you should really have failed a lot earlier. If it's protecting against a tear down race or similar add a comment > + return -ENODEV;