From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 60FB2CA5A for ; Thu, 5 Mar 2026 00:29:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772670583; cv=none; b=lfdgUu2+VSSDeDlFC9LD9OeDVFlt4q6Qi4vYNvDC8B3s1teG/wMuecCGitDEf7YF+wEU0eDNYwezx8NzioctI0LqIh8wSmPDvqnBasSvlwv8+xt93yvq3J4xUp1HNpdFvZz4qVl6PyREq/gYsByyMofRkJqedWGx0ng1Vhv9fiU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772670583; c=relaxed/simple; bh=BIPtPP38tnypiwd1WskyXbCRSqYTysccN8S8I0LJE4g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=u/+36LKXUCFvJBUAEB9X1zGq6lLRcxGtUK3Itz83Kjo/8Ne7fRdKIfRNh6KiEPZH28ZYYpYRkCokBvpHUSvhl9fh3UBA0m8pzU2s4TSDTArR9IAPsX/NnGwZ0bBjV+V4JPzlYroPM7I5cbi2vIjyYMonWQcv9XRbKkoE9R9zNNo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=GbcjlVO4; arc=none smtp.client-ip=209.85.222.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="GbcjlVO4" Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-8cb4136d865so982572085a.1 for ; Wed, 04 Mar 2026 16:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1772670581; x=1773275381; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=fnNZ8h0uyYV+1nNOGA71Wg9+gmZY5aGpsyFvnFBw2lU=; b=GbcjlVO4UajXN3osuSQSGcu08EIYUybVhUD9uOUGrqlF6gFv/tQTeR323IoVmRjVFk rGwQzT/P2fXJqOZir7vXMFa+jmy5XdlccS4VZqgcRTQApOZOdWr2I5gY0HFk2InxsaWH rvtUfpWRZUnNXqNwbZbCSou3YZP8Eb6ajayJeOcIo56LcfiyYQi8QQQYX6ILLQ1M8w2E QEEjKsu4799RNLzOuUiuGH9y3S3UdElK5gO3JUHm1UsS2qHQec8eFC4x9Mct3eXwdDvo mZAWreWjvbCiGYAzJmfL0C4QTmVmVSRGTXkH1cCxyHNROFD5g6d6NehjR7Twct9f19I6 40og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772670581; x=1773275381; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fnNZ8h0uyYV+1nNOGA71Wg9+gmZY5aGpsyFvnFBw2lU=; b=nUtB/y/ubB02niOgMdK2/Ldx9TzJEhg6Vn0DzUk53bQ+ohQLt/uWNz0FImW+v2AAEe lJP/vZORV33F64MVGEoS4ck8rHPKfVnJp1Cd2Nptzyr7i7qc0yrmBGPyIsMmoq4HjhSI HWJH6rAlfGNJaBoEQwoEQvxVI5NFpMcBk/0qmun7VINYqeXo0psHYMrAFP//omugGxUv ZjebOjjlOYjF81Xe3/ueJuUlVPYWyf/8Pv5WDa7Ex+lUXx6/kttG7EjawvvarPhvQAWN 0chiWHVR/sFEzQl75IsIeWQcMoSvoWuwD1iG8/sDoRiKNqljAes6Q93n0c3JZ4RP+wLn Hsrw== X-Forwarded-Encrypted: i=1; AJvYcCWzq3hWqdPhzPM9dKs8NaLKL4LictkCytKYlRA3ddd6xWXS4hnVXceMjlN9jnJ4ZPAAvBqv1jsfwhjPUfI=@vger.kernel.org X-Gm-Message-State: AOJu0YyIrgkof5ayYXLQUvYAk4nru8mrVaN05xMT5p5VAfHqUbP64iPm 6MyfixwZ4lU3lOiMHp7bMS6lRAMhmG5aCKi7dXNizfZEUUp3Y02bQgPCQ7WJuUnNbOpqYu/dm3O 3Qcsr X-Gm-Gg: ATEYQzxsp0EzqIsp0M7/XHqZMv+J1iOK1deorJRdkIEsVMfO32nCtQ7iBnc7/cob41g GOH/TYafjCnzAaOeqDZiuksqwTVFV8wnNM8HWG03r2A5vzhVrvK+DfP/EdBVy0x7hPVjVTShWQU FlvamtNoYB9fhQE5QiJJuym8VQh8NwuceeTx2X4HdgW7P6sMuiG5YMiFkm7silcLtr3W+OgtE43 j8t5gwhYHptfR8Iie8xYT9btLAzwa4AxKyog6zSIgWgu2H8c8FxvtSrnyjE4Ixso+CvFgMG8vYK ezpOGumY61K1CPvuM2NLiKWkge86fsrh35BNp80elshv6fd63wFZQJo0RGnqXzLuHYlwqpK21TC EEwyth7TIMt/1BqXmvqZN9G5H7I34klUPL20+9GghuVRMqi9Rd0dLEHEJTtxKFNsbMcwdAlxtQn gysy4i+W3TOQ0fGt6+kDDAlhvWVS78gfwBlm/1CZolTclywWS4npV2jBXfqYhKniqMF60w4ibPQ 3PxS5sy9Q== X-Received: by 2002:a05:620a:450f:b0:8cb:3bca:bb46 with SMTP id af79cd13be357-8cd5afa3a2cmr517112485a.64.1772670581306; Wed, 04 Mar 2026 16:29:41 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cbbf746fc5sm1736858385a.51.2026.03.04.16.29.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 16:29:40 -0800 (PST) Date: Wed, 4 Mar 2026 19:29:38 -0500 From: Gregory Price To: "Huang, Kai" Cc: "Schofield, Alison" , "nunodasneves@linux.microsoft.com" , "akpm@linux-foundation.org" , "rafael@kernel.org" , "thorsten.blum@linux.dev" , "wangyuquan1236@phytium.com.cn" , "linux-kernel@vger.kernel.org" , "Williams, Dan J" , "lenb@kernel.org" , "xueshuai@linux.alibaba.com" , "linux-cxl@vger.kernel.org" , "linux-acpi@vger.kernel.org" Subject: Re: [PATCH] ACPI: NUMA: Only parse CFMWS at boot when CXL_ACPI is on Message-ID: References: <20260304213342.5776-1-kai.huang@intel.com> <4809035f61dcd6ace773532efe46b0f1928be313.camel@intel.com> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4809035f61dcd6ace773532efe46b0f1928be313.camel@intel.com> On Thu, Mar 05, 2026 at 12:14:52AM +0000, Huang, Kai wrote: > On Wed, 2026-03-04 at 18:56 -0500, Gregory Price wrote: > > > > This basically says if specifically CXL_ACPI is built out, the NUMA > > structure is forever lost - even though it's accurately described by > > BIOS.   > > > > The normal NUMA info described in SRAT is still there. It only avoids > detecting CFMWS, which doesn't provide any NUMA info actually -- that's why > kernel assigns a 'faked' NUMA node for each of them. > > So we are not losing anything AFAICT. Well, I'm mostly confused why there are CEDT entries for hardware that presumably isn't even there - unless this platform is reserving space for future hotplug. Just want to make sure we're not adjusting for strange firmware behavior. The only platform we've seen this behavior on previously was QEMU, but that was because it never emitted SRAT, so i was wondering if there's odd firmware behavior going on (emitting CEDTs when it shouldn't) before we jump to dropping nodes that would have otherwise have been present on existing systems who might have compiled CXL_ACPI out. You are taking something away by nature of compiling something out by default that was previously not compiled out by default. ~Gregory