From nobody Sun Feb 8 04:42:53 2026 Received: from esa5.fujitsucc.c3s2.iphmx.com (esa5.fujitsucc.c3s2.iphmx.com [68.232.159.76]) (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 D62C0450F2; Thu, 10 Jul 2025 02:31:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=fail smtp.client-ip=68.232.159.76 ARC-Seal: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752114702; cv=fail; b=N6H0G5NWMuSgAoyVPMkjIU4fC9kkJ3HsMRRUCCrFosV53Oatsy7HWXZmTHxV4LgtnxzdlppBqn7fe8n7UU8FHRUxSVqRxOtjPFQovv+elxQsNWvieVlNqotUxxtiOevKhVbM2D9cY2K7/4j1UVaPGAGIxAWhXa2bQVh6d7FNr4U= ARC-Message-Signature: i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752114702; c=relaxed/simple; bh=FcFP0m5yS78nH0SRTv5hb3tVGsljZy21N8DwQ7pX90A=; h=From:To:CC:Subject:Date:Message-ID:Content-Type:MIME-Version; b=GFHCdA/cS/AH2IPnUok+GpcavpVqgIR2wLEyuU8rdWqW0NkiyTQZ/kxUHS2hP6pXmBapZC90Bgw/PMJsyYDHeFfTk6eI0A8DZK+OlAMlJHlZGOU2dfr69U4ChqQpTdEfyXzNVLHG16m/ewkNsU8aRqea9k/eXezMzzsf0rktvUM= ARC-Authentication-Results: i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fujitsu.com; spf=pass smtp.mailfrom=fujitsu.com; dkim=pass (2048-bit key) header.d=fujitsu.com header.i=@fujitsu.com header.b=zBnOEvqX; arc=fail smtp.client-ip=68.232.159.76 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=fujitsu.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fujitsu.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fujitsu.com header.i=@fujitsu.com header.b="zBnOEvqX" DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=fujitsu.com; i=@fujitsu.com; q=dns/txt; s=fj1; t=1752114700; x=1783650700; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=FcFP0m5yS78nH0SRTv5hb3tVGsljZy21N8DwQ7pX90A=; b=zBnOEvqXm88wl78ddRQOv7v+YKY/onzHhRaFadJY3VWp4ZtBYKlhHvO/ yDvmjEOrUdbqpoIS94KfTKiu9aR7aSfsMhyj0eD8O/6lyB7nlXFiOCROM 2uyIIs7OhyU1vJJ4jRxUxPXxYAP0WshV8M0eHBMqv3ERaCoWaU4tYZvmr OMmlpuxNEuLkr2I9FGDRNRjbq8TvYL/R4w0rLOWkL/FupBCD/ObSDT6eG NvWSTNKMtMsvO/h6S81jwglpZbVppFXfLnlw9yrrE3J2GqqBYqckEAsJ3 EynwJU3zlQrAPOWxQBXu5HfOmxoGIjDuGjYfSIaDncotdu5XJM3OHfIX6 Q==; X-CSE-ConnectionGUID: K9+xhgaHTIW10hBNwDy8uw== X-CSE-MsgGUID: xJ4lt39jTe+n6vz5XQvcwg== X-IronPort-AV: E=McAfee;i="6800,10657,11489"; a="161517110" X-IronPort-AV: E=Sophos;i="6.16,299,1744038000"; d="scan'208";a="161517110" Received: from mail-japanwestazon11010038.outbound.protection.outlook.com (HELO OS0P286CU011.outbound.protection.outlook.com) ([52.101.228.38]) by ob1.fujitsucc.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2025 11:30:25 +0900 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=gxx5C6PWStdppuvlDDNivOB4Gin0zBDywSy6g/ebhgj4aUroW7op1dQwh2BszXnoGmw8Gbw0F+VXel9z+cJpzyvkkB1mPIcLUsS51TPhzH7OlgV4qTlErXJW3fvur/SSm3kAIwVF77htM632RqrY9gQCRzlp+rSaPHXU2xkqwEUrpiT+lUr1hUGRItQF1qBp9zVcjFY5rDzpo6yIGrGVFb/xv2xGNJNJS+XGZUK4FV9W80Om9V/jxmUposDXOM7+Al1q4QGxMehQbXcIUPXwBGG56kIaIeDpEDMDMZZjKqmqUtcdxGEY/XrADubKBbnAl2cgsY53s/LFQ1iqHeaf4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=FcFP0m5yS78nH0SRTv5hb3tVGsljZy21N8DwQ7pX90A=; b=u3q8Mk9c2iKWMPRRJndM8mjDKWq7hCFM74TIiJtSUbeLOdtoiu5X2Ca0w2JW1+afyIdnFJESVP474bmmZYOZFGploYIAyS6IZOiPKWTgt3w5aj3sxavEeukMN3iRg+iLtdz2REHblT+fm/wVBHVUkiJ/6BKpSPZ4ZRC7XkY2lYaX6jqHJqgyjEomgTQadFdSY7RnHywOtaPx6+A/T2PpHDTKOQJ5uuz5kIs8oQbGW8leUauXrGmM170AuRNOlxMtHsYbqi64DR4aq1RS0GC57qT5fcPvHWK9nWt8I2BKJOksrH7KPiG7eFLLF2zAc9D0mwLi51RR7EcGbVhkhRrYkg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=fujitsu.com; dmarc=pass action=none header.from=fujitsu.com; dkim=pass header.d=fujitsu.com; arc=none Received: from OSCPR01MB14468.jpnprd01.prod.outlook.com (2603:1096:604:3a3::6) by TY4PR01MB15964.jpnprd01.prod.outlook.com (2603:1096:405:2bc::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8901.27; Thu, 10 Jul 2025 02:30:22 +0000 Received: from OSCPR01MB14468.jpnprd01.prod.outlook.com ([fe80::5078:96dc:305b:80e0]) by OSCPR01MB14468.jpnprd01.prod.outlook.com ([fe80::5078:96dc:305b:80e0%5]) with mapi id 15.20.8901.024; Thu, 10 Jul 2025 02:30:22 +0000 From: "Zhijian Li (Fujitsu)" To: "Koralahalli Channabasappa, Smita" , "Bowman, Terry" , Alison Schofield , "linux-cxl@vger.kernel.org" , Jonathan Cameron , "dan.j.williams@intel.com" , "dave.jiang@intel.com" , "vishal.l.verma@intel.com" , Robert Richter , "Fontenot, Nathan" , Gregory Price , Fan Ni , Davidlohr Bueso CC: "Yasunori Gotou (Fujitsu)" , "linux-kernel@vger.kernel.org" , "Zhijian Li (Fujitsu)" Subject: [RFC] CXL/ACPI: Remove overlapping Soft Reserved regions before adding CFMW resources Thread-Topic: [RFC] CXL/ACPI: Remove overlapping Soft Reserved regions before adding CFMW resources Thread-Index: AQHb8UKVhtYBJRdLLUKQA3EsUkYqtA== Date: Thu, 10 Jul 2025 02:30:21 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla Thunderbird authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=fujitsu.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: OSCPR01MB14468:EE_|TY4PR01MB15964:EE_ x-ms-office365-filtering-correlation-id: f989e606-0892-44dc-4ac9-08ddbf59b839 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|1800799024|7416014|376014|366016|13003099007|38070700018|1580799027|921020; x-microsoft-antispam-message-info: =?utf-8?B?S0xjdVJYZU0zR2EyNGlCbnFEM282TmxqcEtXSGRxcnViSFB0SzhzRERvemhm?= =?utf-8?B?VXkwOEE2Z0ptcS83ZzFmakVzT1R1U2hQVUxrQmMydzF6L1lma2p2blRSdzVO?= =?utf-8?B?SUZpNlgyMk1pSFMvd1ZpaTdJSmJhMVRtYVE1V3BCbjI0MUU0Ums0MTNiTjJI?= =?utf-8?B?OHN5aHZpYjdRdVM4YVFyWFk5WHNQMTBNdWNjUjYxMnNIaEJyQSt0M2VvdFBh?= =?utf-8?B?VjBnU3ZGVjdMaGIwSkJGN1lQMGRwd1hYb2hENXE1cWVwOTlnSDFoRUlLYWl3?= =?utf-8?B?cTBQZ1dFNStXN00zK3VBR0RqRHFMS1lBK1V3blVEUTQyd3BEU21ZSVA0U0Rr?= =?utf-8?B?RFg1eWw1OWRnS3ZFaUFCTWF0R1pXc1Z0cGtUNy9iaE0zVW1rTDVGc0ZsdlBC?= =?utf-8?B?em9WdGZ5WjlvNE9YRCsrT1lidDdqUmtSYkVlTDlzQ3VGeVRrZWtaekxxTVVV?= =?utf-8?B?UDJiSnBsQkFGVUNzditqN0tMak5VMDkvT20rWHdCRkVNWWgyYmdOSnRJZnZM?= =?utf-8?B?ZUl4ZVY5SnJjWnZMSHRUSGVSUnVzWWl2WXJXVWwxci84ZjhNZG1YZmpROGdK?= =?utf-8?B?Nm5aYjNSbHZmb3llV21oU3dkbVE1MzFWV1JIYzVSWG5YUVpQa2ZNVkJnS0lZ?= =?utf-8?B?Y0JHNS81UXJRSWhzYlFNMU1yWENQZVBaSFFkWDBzRnZMajB4S0dvZjNtWFVX?= =?utf-8?B?aTZmZ1pDa3ZXMWhuRWgzNVJma0M0b0w3Wm1UYlhjemF2ZE1DVWh4NDdVZ1NW?= =?utf-8?B?K08vcW1uZU94SU91UjIrMHpZays2bElVbloxSFZKcDk3MFhwRms3VXFPcWE3?= =?utf-8?B?bXB1dXhPdnMvUmsra2VSTWk1WTJnSjd4ZGd4YS91clBicDk5bTE0SGFKaHR4?= =?utf-8?B?ejdvUzdLZVR0WENaWExwMTJFQ3pwdktkRUlSbFVQV3FCYmZmR2NFNS9yVDVN?= =?utf-8?B?eEptQlN2RmZySEY2dlhZWGJUeFJITFN2eUd6TUZmb2QrZ2RlZ0c5SXJacDh4?= =?utf-8?B?Nm50dnR4ZGdTK0VyanpBbEhsKzc2ZUE2KzBxLytXbjZyVGQ3M01TcHF3RXlr?= =?utf-8?B?UzBOK3hhV1ZNaGIwVzUwenBObjNINS9hL1lsbGRheGVZeHc1eTZYUVBuMjkv?= =?utf-8?B?ZkFSdEtNdWx3SXJhSWEwSmdkckhuL3BaQm9vSFNvUEtYZFNHTys2WnpEdnBD?= =?utf-8?B?K2tHNzNGbmFoR053aVphNTBwVkVtSnJmK1BxbmVPRERNNStDTVJkbUE5cHN4?= =?utf-8?B?dFdhSkxMN0tjcFc5MlZKL0VaUnhHbzFpd1UxUkhKVXZ2cnh6cGFkbUNGRG5N?= =?utf-8?B?S1phSTBjckVYdCtlODE0SnQ0QlhyNkdpRUFVYmxyVi9PQUJXUng5emZCN1Ez?= =?utf-8?B?ZUY2QkEzZVJaWklQSzhjcTErWXgyRENpQzJQeE5IeTFKTWNXeTVTcm5PWGVj?= =?utf-8?B?STZ4Q3pWYTZIWmpYOFJsNGZTNXQxNlNTS3NlOUdIakplSkhreWt2Sno2ZUJJ?= =?utf-8?B?cWVSb3gvOWRpOSs5UiszODVVT2ZTcGZuZ3ZNcklRZm9PQ3Q0MFNHTnlnc2k4?= =?utf-8?B?UFpHa2dKN3pZb3NtVlNjRjdubTBzWkNwTXh5Ym9hdm1peXdzZ3ptYURPemdV?= =?utf-8?B?ZGpBeXpDZzRRYXo0cWtsOXJtbmNHUHU1TXJER21wTmJucVI4bENyLzJCWVZh?= =?utf-8?B?YXgvaGV0MlBzaUMrRzJBN0pIOXRzbG1hTS9mUkhrUUtCSzFCdzJPSHNLbXpW?= =?utf-8?B?V243RnhXZG4rRzJjamVNTWQzSFF0NzdVd0NZV2NWWmk0Ty9VMlVXUjIvekts?= =?utf-8?B?ZG1ydWs0Mk16eGhpYnU2bUk3MkVVaUNSek9ESEtXanpaNzd0b0R5VCt6bW5G?= =?utf-8?B?KzlBeG4xLzNjYWJWTkplbFNUQmg5MjVhaVpaQTNqSk1Jak1LRUhmNmQ5bzVp?= =?utf-8?B?a0VwaWxxcE9uT0pubXk2d25pb3hiMWo1UEFzVlprTEdEUnBXam9JSTdhYnpX?= =?utf-8?B?QXN1WGgyMHhzVDVsa0hEYzVLWGI5YkZ5U2syODQrSVFPc0ZHcnhBREpjd1VK?= =?utf-8?B?NDg1TTlyTXY2WnREcDFCQUlpZlBJYkszMmN6dz09?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:OSCPR01MB14468.jpnprd01.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(7416014)(376014)(366016)(13003099007)(38070700018)(1580799027)(921020);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?akplWkVYUlJ1ZTJ6UEpCcXlnLzlnZGZ1eE9QMEFzYUJVV3A0d0tud0NDNnVP?= =?utf-8?B?QVVqMG9oRXl3MzBhVmJURm5nbXpZMityQUlTQWVpR2NZZkcxMy9QeUk2b3NQ?= =?utf-8?B?eVRhZThtQ2VaOHBTcHJ3Mit5OGRkZGxBWXM5Vmx5SmppdENZLzVVTUpmTFNQ?= =?utf-8?B?cVVNQUZwbWQyR21iSTk2Slh1R1d6Qm8vTDR4ckxWS25YdXd6LzNnNGhuQWdX?= =?utf-8?B?RGhjZjU1ZkYyZnNvbW94NTZ0YmpDaG40TFkxNWY5ZFcrYzk2L0M1ZUZxRTZ6?= =?utf-8?B?bmtUKzJ6T0MzMnVKeE9CelpSL0c5SE8wZGpzN0I0OEhkUmFDWFlJd1IvU3pC?= =?utf-8?B?MStycEZoOWhxYkl2ckF4ZGtsVlNmVnBZSyt3YVdTT05leEVVb1VtTFY0eDZN?= =?utf-8?B?L3dmTkMxQm1jbzlLNG9MRzhrTGI0K3MySW1DYldLR3pKQWJ6ZldwNVJhN3dx?= =?utf-8?B?L25Rd1k1M3c3OGFVV3drZi9RU1VzaVZwdkoxWndvOFlUWStJSUl5YTJsNUR4?= =?utf-8?B?TjFHQ3p2UXlTMkVpMy8vdDh4a2JZS1lBWDBVWTlrYzZKcGd2N1poUkNhMTFa?= =?utf-8?B?bGdUdXVPc3RHR0JkM05CYkcrVjBMdDNGdWhFRy9xMkdxSTFlT05yWVVRNWIr?= =?utf-8?B?K295YW5heDh6TGRISnNPd25uWDhXWWppeXl2YjFnZGg1b1NJbFc0MTlHeVN6?= =?utf-8?B?OURuSHdCeWtac1dEam45ZGRzRnRoVGJmbnlaOElFeVlEU3hSTmZ4NTB6SUxj?= =?utf-8?B?NUFqWnppMWF3VjdhTFI4emVtemcxZGNGWm5VeVJhd2lEU29WWUd0T0Nub2Zl?= =?utf-8?B?MlpqMFBKSGltajdCZXh0OEt0aUYzL2xUM1c5MUhIL3BUOHIrUSt0ZDd1d0h4?= =?utf-8?B?akFJVHJ3em1DOHY2OFVFTGd6dkVTTUlRdzY4WmVRQXkxQ3dOaDR2a2dwVDg4?= =?utf-8?B?d011ZDFjODkxaFJEci85WVJYNDBBZWNURkZBeGZUdzM3SE9nU3VBQWt4MWVh?= =?utf-8?B?SkE0c3hkeVlFcUNQTjBoWUtIVER1TGhXbUVZemNmZ0N0WHhzNndVTVZZOGJO?= =?utf-8?B?RlBwT0lhYTlkYk83SzljcFFRM0p3NVJUZkNNVmFVZXFzN1MycDVUNmRlc3k2?= =?utf-8?B?aE1JUk93Vk92WGR0V0l4aWJ4Z3p2K1JraU1XMHFGWUFpblpkVDdnL3RGZmYz?= =?utf-8?B?cVdjVGV6eUNNTTdPaFdtQlNvT254WXN2bS9maDZIUGx6Unpkc245RldaMGRy?= =?utf-8?B?enYwR29Eem1odmRDcVBqRG91N3FEZnV2eTBzL1FXdFNKcUZqTkdSZ1RzVUlr?= =?utf-8?B?ckptQy9qc2UweWtRQ25HSU1uc1d5UnlCYkxtbDE3VFAyMXJBSkpKcDlVK2VG?= =?utf-8?B?QmJvcDBMbGFKSHVPZERrTE5FQjlrOHZ4VC9HSmZmRTIzM2I5Q3UvSkQ1ZUVN?= =?utf-8?B?ZlZ6bGplejErYjY3eWcrUVZFcHpmcVh2VjNyODc3cDRkMmdiejljNG9MeVMy?= =?utf-8?B?UDZRSWxpc1dmTFJIektQbG9yL2ZiNm9tMDVnTEVwbjAxVUUxSStaOUxBY2wy?= =?utf-8?B?cHdUbFoybWNSY3l2b2FYRHdhcURCbWlWcmJhZytNRTZseVJob1ZwU1N0TDVX?= =?utf-8?B?MWp2OHpuelV0dDdSUDhYcWZka0preS9UUFZFTTRtd1BIOE5tZjJTT0lFczVT?= =?utf-8?B?ZGZPcnAzNnU2NmpTVDNiVUxoMGp4VWtiUjR5V2cwSlNUTWdNaEl5eGlHYjZY?= =?utf-8?B?SXhjOFJZOTNLc1lOWEhYNUdTS0k2YVo5aDhnc255alIwcFBHQVprZDhHVTlF?= =?utf-8?B?WHJnT3lIclU2TFZOZkd2VXRPSk91dHFwMkZvM2RyVkVTejR3UlpHRCtnUVdJ?= =?utf-8?B?dTluNjZCSXdvQmVFZ3E5bG5DQ256QStzZkRMcWhXRFBpeDRPMVdoVi8wdzZw?= =?utf-8?B?MEl5R0lKeUsxQnZXZlhwOThpb0dsRDlNOGZSeHdNTUo0WTZEdjM0eE1iejBB?= =?utf-8?B?c0J4QnhwWHd2L2p2VHhEWnpBeS8vc2xVczBzYWNRT2ZjdENFRXAyRjVCT0g2?= =?utf-8?B?c1ZLZFVQVUQwTjVYZm12V0szVlNnQU9GcDAzQU9adU1aUDVoUGt5OXEwcE9x?= =?utf-8?B?ZmN1K2pOUEZTUGg2dGp2c0x4VUwvaElKeHIva2pOcHlNNUhhWkpSTUVrS2sx?= =?utf-8?B?TkE9PQ==?= Content-Type: text/plain; charset="utf-8" Content-ID: <0B128511877C4D4A9B26F0FBE5E4DF92@jpnprd01.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: cMhRlcDHibkOXnBbuTMuigAByJLaNEuXVjldiBjPnz+aH5aLM5iq+A9oaiG9HLQu3at2XJHkuenea5WWTF3y1DGlrpMuzz5ka5C9IkSIV7sS7bu4ilEV6hun0172nGg7Cpyq2/bcUN6BHRWp0oWhi/Vm5twaaSHzZ9kFZmgUwVTxNEP5lUaTRSla8bq2I19VW5MQaeeu+GLqPJRaIwzvcB+u0nRnB0hXvS9gRTlvp/csY7ZPDiRfdPrUweUKNPeS9ae1OpAzUNLndOJ3nFR9kOU2Ri+3cYg42tBxN+YUHBTBfQogc3zMpe+I+kISjAJsrx9/D+2nflacSc+7e3Yul1piVKgxqyrS0ktN8Qmk+OOBrLMRYRIsW0CoqflZEupOApdWSuOQf0+6EW/oP/eS51YBGo5/K109D2D0mRiq+yPLy52jy09D4WBV6Bv1a1kR5eakRyiZ76rg/gA4MGcRbu7dORQqr4FYLBzFBRB/m8pm6urlyFLgTr0w37B5J29ln44fPDC+9B8KQpY0/kMeLXcGRyvhJ5+ZRk1SZhq9ySjsfHO0PC0WoILbeUiV5fkM40uy+Brv0k/3uQ0emlfCjzXEY2Rz7kmGUUK+hXkbLfX9keYN6WfUmvR9m9fKYO1P X-OriginatorOrg: fujitsu.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: OSCPR01MB14468.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f989e606-0892-44dc-4ac9-08ddbf59b839 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2025 02:30:21.9902 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a19f121d-81e1-4858-a9d8-736e267fd4c7 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8T/Am0d2HnhoHeYpjz6ai01NYGZbkm9KEPUUQrQUOyJPDj8TOP4dBbVnMpVEfb+Fxo9c9aXOsWToWjwDzOg4vA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY4PR01MB15964 Hi all, This RFC proposes a new approach to handle the resource conflict between CX= L Fixed Memory Windows (CFMW) and "Soft Reserved" memory regions. I've been thinking about the "Soft Reserved" issue lately and went through = the previous proposals [0]. The existing solutions are generally centered a= round CXL region management. For instance, an early proposal [1] suggested = removing the "Soft Reserved" resource during region teardown. The current a= pproach [2] has evolved to remove it after the CXL driver automatically con= structs a CXL region. I haven't found prior discussions centered on removing the "Soft Reserved" = region *before* the CFMW resource is even added. If this has been discussed= before, please point me to the thread. My proposal is to remove the "Soft Reserved" resource at the moment we add = the root decoder resource (the CFMW) from `CXL_ACPI`. Here=E2=80=99s why I believe this is feasible and more effective. #### Background Currently, CXL memory can be exposed to the users in several ways(1)(2)(3),= depending on firmware and driver configurations. The diagram below illustr= ates the flow: ``` +-----------------------+ | | | CXL memory | | | +----------+------------+ +------------= ----------+ | | = | | | = | +firmware---------------------+ | = +---------v---------+ +--------------+ | v | | = | | NO | | | +----------+-------------+ | | = | enable CXL_ACPI? +---------> HMEM | | | | | | = | | | | | | expose to E820? | | | = +-------------------+ +-------+------+ | | | | | = |YES | | +----------+-------------+ | | = | | | | | | = +---------v----------+ | | | YES | | = | iomem | | | v | | = | CXL WindowN | | +-(1)-----------+ | +-----------+-------------+ | | |= (4) | | | iomem | NO | | set | | | += ---------+----------+ | | System Ram +<--------+ EFI_MEMORY_SP attr? | | | = | | | | | | | | | = | | +---------------+ | +-------------------------+ | | += ---------v----------+ +-------v--------+ +-----------------------------+ | = | | | | | YES | = | CXL region +--------> (2) dax/kmem | v | = | | | (3) device_dax | +-----------+-------------+ | = +--------------------+ +----------------+ | iomem | | | Soft Reserved +--------+ | | +-------------------------+ ``` The problem we are facing occurs in path **(4)**, where the ACPI-defined `C= XL WindowN` (CFMW) overlaps with a `Soft Reserved` region. In this scenario= , if we try to destroy the driver-created CXL region to create a new one, t= he operation fails because the underlying memory range is still claimed by = "Soft Reserved". Here is an example from ` /proc/iomem `: ``` c070000000-fcffffffff : CXL Window 0 c070000000-fcffffffff : Soft Reserved c070000000-fcffffffff : region0 ### Deleting this will not free the r= ange for a new region c070000000-fcffffffff : dax0.0 c070000000-fcffffffff : System RAM (kmem) ``` #### Proposal The fundamental assumption of the CXL driver design appears to be (and I be= lieve this is correct) that once the kernel successfully parses `CEDT.CFMWS= ` via `CXL_ACPI`, the CXL subsystem is designated to take full control of t= he corresponding CXL memory device. If this holds true, it means that the "Soft Reserved" region, which serves = as a firmware-level hint to prevent the OS from arbitrarily using this memo= ry, is no longer necessary after the CFMW is identified. The CFMW itself be= comes the authoritative definition for this memory range. Therefore, we can safely remove the "Soft Reserved" resource from the `iome= m_resource` tree right before inserting the new CFMW resource. This approach is simple and highly effective. It decouples the "Soft Reserv= ed" problem from CXL region management entirely. By cleaning up the resourc= e conflict at the earliest possible stage, this solution should be compatib= le with all CXL region patterns, including scenarios with misconfigured or = unconfigured HDM Decoders. I haven't spent much time working out all the implementation details yet, b= ut a quick proof-of-concept (PoC) shows that this approach appears to work.= A rough sketch of the code is below. If this direction is ACKed, I will pr= epare and send out a complete implementation for review. ```diff --- a/drivers/cxl/acpi.c +++ b/drivers/cxl/acpi.c @@ -780,7 +783,9 @@ static int add_cxl_resources(struct resource *cxl_res) */ cxl_set_public_resource(res, new); =20 - insert_resource_expand_to_fit(&iomem_resource, new); + /* Remove Soft Reserved that is fully covered by this window */ + claim_and_punch_out_soft_reserved(&iomem_resource, new); =20 next =3D res->sibling; while (next && resource_overlaps(new, next)) { ``` And the new helper function in `kernel/resource.c`: ```diff --- a/kernel/resource.c +++ b/kernel/resource.c @@ -364,6 +355,7 @@ int release_resource(struct resource *old) =20 EXPORT_SYMBOL(release_resource); =20 +/** + * claim_and_punch_out_soft_reserved - Claim a resource region, punching o= ut + * any overlapping "Soft Reserved" areas. + * @root: The root of the resource tree (e.g., &iomem_resource). + * @new: The new resource to insert. + * + * Description: + * This function prepares for the insertion of a new resource (@new) by + * resolving conflicts with existing "Soft Reserved" regions. It works as + * follows: + * + * 1. It iterates through the children of @root, searching for any resource + * that both overlaps with @new and is identified as "Soft Reserved" + * (by its name and the IORES_DESC_SOFT_RESERVED descriptor). + * 2. For each conflicting "Soft Reserved" resource found, it removes the + * original conflicting resource from the tree. + * 3. It then calculates the remaining parts of the original resource that + * lie outside the range of @new. This may result in one or two smaller, + * non-overlapping parts. + * 4. These remaining parts are re-inserted into the resource tree as new, + * smaller "Soft Reserved" resources. This action is akin to "punching a + * hole" in the original reserved region. + * 5. After all conflicts are resolved, the @new resource is inserted into + * the tree, claiming the now-available space. + * + * Return: 0 on success, or a negative error code on failure. + */ +int claim_and_punch_out_soft_reserved(struct resource *root, + struct resource *new); + ``` Looking forward to your feedback and thoughts on this approach. Thanks, Zhijian ----- **References:** [0] [PATCH 0/2] cxl/region: Improve Soft Reserved resource handling: [https://l= ore.kernel.org/linux-cxl/cover.1687568084.git.alison.schofield@intel.com/](= https://lore.kernel.org/linux-cxl/cover.1687568084.git.alison.schofield@int= el.com/) [PATCH v2 0/2] cxl/region: Improve Soft Reserved resource handling: [https:= //lore.kernel.org/linux-cxl/cover.1691176651.git.alison.schofield@intel.com= /](https://lore.kernel.org/linux-cxl/cover.1691176651.git.alison.schofield@= intel.com/) [PATCH v3 0/2] cxl/region: Improve Soft Reserved resource handling: [https:= //lore.kernel.org/linux-cxl/cover.1692638817.git.alison.schofield@intel.com= /](https://lore.kernel.org/linux-cxl/cover.1692638817.git.alison.schofield@= intel.com/) [RFC] cxl: Update Soft Reserved resources upon region creation: [https://lo= re.kernel.org/linux-cxl/20241004181754.8960-1-nathan.fontenot@amd.com/](htt= ps://lore.kernel.org/linux-cxl/20241004181754.8960-1-nathan.fontenot@amd.co= m/) [RFC v2] cxl: Update Soft Reserved resources upon region creation: [https:/= /lore.kernel.org/linux-cxl/20241030172751.81392-1-nathan.fontenot@amd.com/]= (https://lore.kernel.org/linux-cxl/20241030172751.81392-1-nathan.fontenot@a= md.com/) [PATCH] cxl: Update Soft Reserved resources upon region creation: [https://= lore.kernel.org/linux-cxl/20241202155542.22111-1-nathan.fontenot@amd.com/](= https://lore.kernel.org/linux-cxl/20241202155542.22111-1-nathan.fontenot@am= d.com/) [PATCH v2 0/4] Add managed SOFT RESERVE resource handling: [https://lore.ke= rnel.org/linux-cxl/cover.1737046620.git.nathan.fontenot@amd.com/](https://l= ore.kernel.org/linux-cxl/cover.1737046620.git.nathan.fontenot@amd.com/) [PATCH v3 0/4] Add managed SOFT RESERVE resource handling: [https://lore.ke= rnel.org/linux-cxl/20250403183315.286710-1-terry.bowman@amd.com/](https://l= ore.kernel.org/linux-cxl/20250403183315.286710-1-terry.bowman@amd.com/) [PATCH v4 0/7] Add managed SOFT RESERVE resource handling: [https://lore.ke= rnel.org/linux-cxl/20250603221949.53272-1-Smita.KoralahalliChannabasappa@am= d.com/#r](https://lore.kernel.org/linux-cxl/20250603221949.53272-1-Smita.Ko= ralahalliChannabasappa@amd.com/#r) [1] [https://lore.kernel.org/linux-cxl/cover.1691176651.git.alison.schofiel= d@intel.com/](https://lore.kernel.org/linux-cxl/cover.1691176651.git.alison= .schofield@intel.com/) [2] [https://lore.kernel.org/linux-cxl/20241004181754.8960-1-nathan.fonteno= t@amd.com/](https://lore.kernel.org/linux-cxl/20241004181754.8960-1-nathan.= fontenot@amd.com/)