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 665EB3D4112 for ; Wed, 15 Jul 2026 22:26:08 +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=1784154370; cv=none; b=N4Z6KevhbbSyuPbcDejTbp4Kq8t6XWvn3yHKQ4XfVZGY607hKgjLNTUJfoSxAyFAEjcXwNpjqU/zRrRa7qzCjR1+yqQ+wl+JzOU/bJBVO9P1KYSeF1b7OeAwroKKMvD7U3vLbfFdwL0GUTi6SAXub96WjfINnceEY9BcuhhBE9I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784154370; c=relaxed/simple; bh=OEcNvjwk6pc1GWy+0beqfMS3+K+DDDS1POR3nHWjm2U=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=gz4Ck1m4R2Sn5PNjoAgMzAduPdm9c8yEA09wWB99l3E3fXNNSd9MccaydUFke+h9pfQ7tHLSYn9y8Vxq2rWE0b6mNvu8SbIpwzj4YS3Yc/sHiZS2pY7tHp+YDv3CDYU7k30y6d6zx+QON9nFPIy0w5BTlNSZW93DaDCJlVDIEP0= 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=hiuYYeKY; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=F63Hi9Np; 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="hiuYYeKY"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="F63Hi9Np" Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 66FKPS8D596073 for ; Wed, 15 Jul 2026 22:26:07 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= aPE9hDY7OVlCjZI5zzGvMOmszedQ4sO74FdAg6irg6I=; b=hiuYYeKYGd1pkP4G ugPmm9bIbvq99F3YtqXnllNQoBgTu1gm2vL1KYRFoCPL9SjUov8byoUguLjoqEAo XLr6g/Onu66m80psEDaM/nmiStU99pXmuHZD09pe1oj6KBTJp+EpI4hJUtd6WGZx tR31AdhNTl1z1wZYEE3MX2WiTc+t+PhYumSlhrny453xvgc44TrRygYibD4X16ZP ku54PG7rPk9GfbpMiv98Eu+hKHYtiseMcPBkC+9u5c6uY5uQ4jP3cNFPm7smKPWC kjGqmoPtnQnta+/pW/YS0sBmxHrzS+dlvYuRy/r9ys+l+U8588FSdsgi7fySe7dk 6ZsoOQ== Received: from mail-pl1-f197.google.com (mail-pl1-f197.google.com [209.85.214.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4fe7q62xnt-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 15 Jul 2026 22:26:07 +0000 (GMT) Received: by mail-pl1-f197.google.com with SMTP id d9443c01a7336-2cd01a14e81so87127605ad.1 for ; Wed, 15 Jul 2026 15:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1784154366; x=1784759166; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=aPE9hDY7OVlCjZI5zzGvMOmszedQ4sO74FdAg6irg6I=; b=F63Hi9NpYAfxcN76JzXlLOVmaCt3A0nUp1TFEBXT1w15O+b0sBz2ZuZpI3yWFt1gds 7b/lNT/py9o4kmGLSHKUVn9jyt0YDWeVqNXvmKQzOM9TB7Iz8J8HUMDzNfPwOzsoMwER iOVSCG4AmduaEdiJD8mj0cyuJf08gebvAO84Bs0VtjqN67gLHb1c+C96B2AT633eGoFr oBx6HXKIoxe1c3LsVIeNfMppsrDT8t5Vix7Xg5qDW7y5axxf1mZVdHNV9AIUohgw9Qd/ jn4jzbfDwtWbXsS4BTuAZqbMyiX6esnEh4fIdn2tI+MCT7JRlu9FEMNX+0v67xvX+T6D tcQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784154366; x=1784759166; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=aPE9hDY7OVlCjZI5zzGvMOmszedQ4sO74FdAg6irg6I=; b=P7S8auSJbByrCe7I6kzwn2q+cnJX0GVr6wCMnOAx3HptKAc86pML0oOvyoyd2gcopv ZH0I+6jhfwy4MtmwZvkLyMINva/yXQ0afn0GBv7j1JgI6e6DXw44Ydg8IWuLZsKRh50P mJY1y+6+8lAbLdM5y3to2C8h0SJFxtp/xgJxeosoWaPH9ke0TVskNrKi6hM7rDybqTNb sY956mKhTM7aaG8SJYBM7mED3Cum9m70G/ewBca+jgjKAw1KEMroq521tYWjVuCwOBvL Nb3odQa/AZVVUj9RoH09fmCdwceUH7XVlFni2rw6BjbEt5aZOk9gmJRtLqXKyKYyTztV HRQQ== X-Forwarded-Encrypted: i=1; AHgh+Rr4EyPbgLuSgXBSm3bsKIkX4Cj1K+s3Nw3fWWeBzoSrjt4zAbXuMAEOLFVUA/80FffyB3X98BEEvHTjWLM=@vger.kernel.org X-Gm-Message-State: AOJu0YzGQkJdJQ69GOJkreaq8VAIQGE5gI9Pl22UFECiNJtYnMKo19Sb Megj3tiBELb0xLHI6vo8jQb9nEg+RLfAMH+V6BVHrWZWdqmETk9UBEptsjO7vDyde6M8ybsYnI6 tPxVBx5tbK4Dcox50wL+ErYE6Vkbeu9zzNfkIRm0wG0RUg12zJ8nHev/xp3eZWCfdJJw= X-Gm-Gg: AfdE7cl5PR6Yd3vQ9JTTCw/wi6nOAfgY1es+BMwsR30uVPjFhIy3wpn4c/A56IngmXx W5YJplxyHpJ6ZDtytIz70Z+0pOCBvsFH+53I9dSMExk7Ztz3k2MS0EaBMgWeYo/Opr8XPmHtFb6 2ULBgNABzJOS7h1/yK+RugoImL/hWTm7Eg0irfgCAcFzVZ/CO25D8ladqF7bAJ1lSpeCIRiqYkF UOmhgzd2p4PEnopNYq3RTRpWNT0LnONoCpCEj/6O7d0WcjjN2x/UAXVlx32Ud0T0l0BLgND3sN2 fWUjoNewHY9xkP0NhD/Jym9k/LICXWTMFr5NwA81o2QnA0OjbRW0CfuaU3nzbAMS38tym8woEgl 55/FTKJIAEBnfLCtyD40n2NjCI3OnuhQcm12PWKlw/OCt0JycLWM0yxgg X-Received: by 2002:a05:6a20:9183:b0:3bf:d62f:44e1 with SMTP id adf61e73a8af0-3c36c35d250mr5223453637.53.1784154365922; Wed, 15 Jul 2026 15:26:05 -0700 (PDT) X-Received: by 2002:a05:6a20:9183:b0:3bf:d62f:44e1 with SMTP id adf61e73a8af0-3c36c35d250mr5223421637.53.1784154365394; Wed, 15 Jul 2026 15:26:05 -0700 (PDT) Received: from [10.71.178.173] (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-13cd428b2d3sm4015017c88.5.2026.07.15.15.26.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Jul 2026 15:26:04 -0700 (PDT) Message-ID: <115d2157-d4d2-4897-a9c8-fe42fec0bbf9@oss.qualcomm.com> Date: Wed, 15 Jul 2026 15:26:04 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] cxl/hdm: Enforce CFMWS memory type policy at decoder commit time To: Dave Jiang , linux-cxl@vger.kernel.org Cc: dan.j.williams@intel.com, ira.weiny@intel.com, vishal.l.verma@intel.com, alison.schofield@intel.com, linux-kernel@vger.kernel.org References: <20260711003341.2602368-1-mayank.rana@oss.qualcomm.com> <61531e60-0171-4d7e-b61b-ac0790a38ede@intel.com> Content-Language: en-US From: Mayank Rana In-Reply-To: <61531e60-0171-4d7e-b61b-ac0790a38ede@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Info: AW1haW4tMjYwNzE1MDIyNCBTYWx0ZWRfX8Bme2bknlXvW 9FzoZR3o0iBcb9HkmMgu0zXszOWpgpUdOqIII5oaWfcvrLzmpHHSkEXSD8TX+fC+hvMS8NpvAAr Z3XMTlDB3hVA9UwDZAR7fj04NeZ1UJg= X-Proofpoint-ORIG-GUID: EOO46SOR--CTw-C3gZbzbJgC74UtIMwC X-Proofpoint-GUID: EOO46SOR--CTw-C3gZbzbJgC74UtIMwC X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzE1MDIyNCBTYWx0ZWRfXzK8I78pySaeD VY/nYh/DKwBiF2cgbsbqMHvnWX8EMYn6Wz7F+ouDKSQLN5WIFRd1Y1tP/WbcnyxGjx1uChUPsZp bGdR3N4Q93WoJVeXe8qEf4Z7FZ6UH3EU0iySF+KkM6qj2J/eISfiMC3EaZfaGyTIRMa4OVwDVmX 3qdEFGSU1k13w8dyhD5+E0EUhONEvAP2U0YQqpjGUKROGIu7J97pVJOZsrVTXjn/j88/D6gwUQq OnBeV7jcfyNp4SvCxXeF/jsy/Sa4bcgCMA6sjdPJSXkENdBEr9hS/e/zWVng/xf9YUKV+9tsZW9 M92LNbUXE5PnEYQumtSRq8g63SBTm7A6iTIXv32HMwx5u6gFNwIv1dh3jmy3fZWJjF4gbnCvgUh xVTBlfmDmu7qDoowyAQ0ZwuuZcpZdJBIkcYFW0auQzF/UfrFGF0zRTaR0HWrOLpaXz9Tvs3h8s8 OuO3T0UW41x+FEr5hUQ== X-Authority-Analysis: v=2.4 cv=BajoFLt2 c=1 sm=1 tr=0 ts=6a5808ff cx=c_pps a=cmESyDAEBpBGqyK7t0alAg==:117 a=JYp8KDb2vCoCEuGobkYCKw==:17 a=IkcTkHD0fZMA:10 a=RAioF0-LDSMA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=EUspDBNiAAAA:8 a=2aGvtvhTeeNcsLIwH_MA:9 a=QEXdDO2ut3YA:10 a=1OuFwYUASf3TG4hYMiVC:22 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-15_05,2026-07-15_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 phishscore=0 malwarescore=0 clxscore=1015 bulkscore=0 impostorscore=0 adultscore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2607150224 Hi Dave Thank you for review comments. On 7/13/2026 8:47 AM, Dave Jiang wrote: > > > On 7/10/26 5:33 PM, Mayank Rana wrote: >> A CXL Fixed Memory Window Structure (CFMWS) in the ACPI CEDT table >> carries a restrictions field that describes the memory types a platform >> window supports. cfmws_to_decoder_flags() translates this into >> CXL_DECODER_F_TYPE2 (HDM-DB permitted) and CXL_DECODER_F_TYPE3 (HDM-H >> permitted) flags on the root decoder. >> >> However, nothing currently prevents a caller from committing an endpoint >> or switch decoder whose target_type conflicts with the CFMWS policy: >> >> - A decoder with target_type == CXL_DECODER_DEVMEM (HDM-DB) can be >> committed on a window that lacks CXL_DECODER_F_TYPE2 (HDM-H only). >> A dual-capable device will accept HOSTONLY=0 + COMMIT=1 without >> asserting COMMIT_ERROR, silently violating platform policy. >> >> - Symmetrically, a decoder with target_type == CXL_DECODER_HOSTONLYMEM >> (HDM-H) can be committed on a window that lacks CXL_DECODER_F_TYPE3 >> (HDM-DB only), again violating ACPI CFMWS restrictions. >> >> Add a check in cxl_decoder_commit() that walks from the decoder's >> assigned region to the root decoder and rejects the commit with >> -EOPNOTSUPP if the decoder's target_type requires a capability flag that >> the CFMWS window does not advertise: >> >> - CXL_DECODER_DEVMEM requires CXL_DECODER_F_TYPE2 on root decoder >> - CXL_DECODER_HOSTONLYMEM requires CXL_DECODER_F_TYPE3 on the root >> decoder >> >> required_flag is initialized to zero so that any future target_type >> values not covered by the if/else-if chain leave the enforcement check >> a no-op via the leading required_flag && guard. >> >> This makes the CFMWS restrictions field authoritative for memory type >> enforcement in both directions, regardless of individual device capability. >> The existing COMMIT_ERROR path in cxld_await_commit() remains as a >> secondary safeguard for devices that cannot support the requested mode. > > Can you please trim the commit log? The AI generated verbiage is excessively wordy. A simple and more to the point short log that conveys all the information would be appreciated. ok. noted down. >> >> Fixes: 3e23d17ce198 ("cxl/acpi: Use the ACPI CFMWS to create static decoder objects") >> Assisted-by: Claude:claude-sonnet-4-6 >> Signed-off-by: Mayank Rana >> --- >> - Initialize required_flag = 0 and use explicit else-if for >> CXL_DECODER_HOSTONLYMEM; guard enforcement with required_flag && >> so unknown target_type values skip the check cleanly >> >> Changes in v2: >> - Extend enforcement to cover both directions: HDM-H commits on >> HDM-DB-only windows are now rejected in addition to HDM-DB commits >> on HDM-H-only windows (reported by Sashiko AI review) >> - Generalize condition from single DEVMEM check to type-dispatch >> selecting required_flag based on target_type >> - Update commit message and subject to reflect bidirectional policy >> >> Testing >> ------- >> >> The bug and fix were validated using QEMU with a modified CXL configuration. >> >> Two test-only changes were applied (not part of this patch): >> >> 1. QEMU ACPI (hw/acpi/cxl.c): CFMWS restrictions field changed from >> 0x0f to 0x02 (ACPI_CEDT_CFMWS_RESTRICT_HOSTONLYMEM only, without >> RESTRICT_DEVMEM). This causes cfmws_to_decoder_flags() to set >> CXL_DECODER_F_TYPE3 only on the root decoder, simulating a platform >> that does not permit HDM-DB. >> >> 2. Kernel (drivers/cxl/core/hdm.c): init_hdm_decoder() uncommitted >> endpoint path changed to force CXL_DECODER_DEVMEM unconditionally, >> simulating a dual-capable device (supports both HDM-H and HDM-DB). >> QEMU's cxl-type3 device reports CXL_DEVTYPE_CLASSMEM and defaults >> to HOSTONLYMEM; this override exercises the DEVMEM commit path that >> a real Type-2 or dual-capable Type-3 device would trigger. >> >> Bug reproduction (without this patch): >> >> # cxl create-region -m mem0 -d decoder0.0 -t pmem >> created 1 region >> >> HDM-DB committed silently despite CFMWS advertising HDM-H only. >> No error or warning in dmesg. >> >> Fix validation (with this patch): >> >> # cxl create-region -m mem0 -d decoder0.0 -t pmem >> cxl region: cmd_create_region: created 0 regions >> >> dmesg: >> cxl_core: cxl region0: mem0:decoder2.0 type mismatch: 2 vs 3 >> cxl_port endpoint2: failed to attach decoder2.0 to region0: -6 >> >> The decoder's target_type (2=DEVMEM) mismatches the region's required >> type (3=HOSTONLYMEM) enforced by the CFMWS restriction -- commit blocked. >> >> QEMU invocation: >> >> qemu-system-x86_64 \ >> -kernel bzImage \ >> -append "root=/dev/sda rw console=ttyS0" \ >> -drive file=rootfs.img,index=0,media=disk,format=raw \ >> -M q35,cxl=on -m 4G,maxmem=8G,slots=8 -smp 4 \ >> -object memory-backend-file,id=cxl-mem1,share=on,mem-path=/tmp/cxltest.raw,size=256M \ >> -object memory-backend-file,id=cxl-lsa1,share=on,mem-path=/tmp/lsa.raw,size=256M \ >> -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \ >> -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \ >> -device cxl-type3,bus=root_port13,persistent-memdev=cxl-mem1,lsa=cxl-lsa1,id=cxl-pmem0,sn=0x1 \ >> -M cxl-fmw.0.targets.0=cxl.1,cxl-fmw.0.size=4G \ >> -nographic >> >> >> drivers/cxl/core/hdm.c | 29 +++++++++++++++++++++++++++++ >> 1 file changed, 29 insertions(+) >> >> diff --git a/drivers/cxl/core/hdm.c b/drivers/cxl/core/hdm.c >> index 0c80b76a5f9b..127a187cdadb 100644 >> --- a/drivers/cxl/core/hdm.c >> +++ b/drivers/cxl/core/hdm.c >> @@ -802,6 +802,7 @@ static int cxl_decoder_commit(struct cxl_decoder *cxld) >> struct cxl_port *port = to_cxl_port(cxld->dev.parent); >> struct cxl_hdm *cxlhdm = dev_get_drvdata(&port->dev); >> void __iomem *hdm = cxlhdm->regs.hdm_decoder; >> + struct cxl_root_decoder *cxlrd; >> int id = cxld->id, rc; >> >> if (cxld->flags & CXL_DECODER_F_ENABLE) >> @@ -834,6 +835,34 @@ static int cxl_decoder_commit(struct cxl_decoder *cxld) >> } >> } >> >> + /* >> + * Enforce CFMWS memory type policy: reject commits where the decoder >> + * target_type conflicts with the root decoder's CFMWS restrictions. >> + * - HDM-DB (DEVMEM) requires CXL_DECODER_F_TYPE2 on the root decoder. >> + * - HDM-H (HOSTONLYMEM) requires CXL_DECODER_F_TYPE3 on the root decoder. >> + * - Unknown target_type values leave required_flag zero; skip enforcement. >> + */ >> + if (cxld->region) { > > I don't think we should gate the check based on whether cxld->region is valid or not. Can you please take a look at core/region.c:271:cxl_region_decode_reset() and do something similar to acquire the root decoder by walking up the port hierachy? That should apply the policy check unconditionally. I would also suggest putting this entire block in a helper function. will refer suggested API, and rework upon this. > DJ > >> + unsigned long required_flag = 0; >> + const char *type_name; >> + >> + cxlrd = to_cxl_root_decoder(cxld->region->dev.parent); >> + if (cxld->target_type == CXL_DECODER_DEVMEM) { >> + required_flag = CXL_DECODER_F_TYPE2; >> + type_name = "HDM-DB"; >> + } else if (cxld->target_type == CXL_DECODER_HOSTONLYMEM) { >> + required_flag = CXL_DECODER_F_TYPE3; >> + type_name = "HDM-H"; >> + } >> + >> + if (required_flag && !(cxlrd->cxlsd.cxld.flags & required_flag)) { >> + dev_err(&port->dev, >> + "%s commit rejected on %s, CFMWS does not permit this memory type\n", >> + type_name, dev_name(&cxld->dev)); >> + return -EOPNOTSUPP; >> + } >> + } >> + >> scoped_guard(rwsem_read, &cxl_rwsem.dpa) >> setup_hw_decoder(cxld, hdm); >> > Regards, Mayank