From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) (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 046B01798F for ; Wed, 15 Jan 2025 02:23:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736907822; cv=none; b=tmfvUqAp84sbK2t4pI/94GYrTqHyls2fwlniYPjzeirpheG9vsS+IX3mFDUACnKOAjgaUm1qOQTMWTQSDJE2PzK6lQ1ZkXH/1+0zOZ9+4RG4Zmvg+xi0z1p0x3Wjaxlv7tJPXRELzM8ii89HQwXkmQK3D6hjNUf3CBGsKDJAp5Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736907822; c=relaxed/simple; bh=o/P5O0ePktq8VUtCRPX3dltyt6nu7IWQDbM6nRTtctE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=VGlpM2WY/yfNJ9oosF9Xj25ZOujcaMj/SGapai2NY/3ozrRzcCIr9BQBzsHfgI8fBkZcb+bBKkaeQr5o10YFVF8XD2iSbDTlSXhjnk6G+84QeaXjf4CYSuO4QnAHIF++NwAIaVWhHoqL8Mu+mHzusw3JqJtqGlqsXfyWj3vLd1A= 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=uE0kB0Bj; arc=none smtp.client-ip=209.85.160.177 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="uE0kB0Bj" Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-46901d01355so60131331cf.0 for ; Tue, 14 Jan 2025 18:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1736907820; x=1737512620; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=peWTTYrtZ7J6rEfihyYy+2RDFnwMGAeDvIy5UrD7uQI=; b=uE0kB0Bj0hGelOvIyMjEUNE4xmx+v1sQEiHYXn7gwJcwkZe6+nNslvrOPiudwK4SmA CddYwZibgUzL0Fguw1DpFJjXry/lAYPXApQuooK0weYRa8l1PDff8VnMcEEgg4tM+5Cj xEAQXRKO0Mz3JGB22v2De1PpC1O+VrI7+S9TFPgO/l22UpbfmTtWIw3dy0macE18Bmmt Y5pfKR1eQUpyuA6/fsTRefJzkXqfziQ89rkSLAUo3RpWrH0EmB+jSNy2QSCZKSPoHHbe AIasGcXktfATvxNcZn3AyJSdhfXIbvsjkiqU0U60/sh5mEvjdl8waPYLg/gAxmMJYSMH dh3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736907820; x=1737512620; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=peWTTYrtZ7J6rEfihyYy+2RDFnwMGAeDvIy5UrD7uQI=; b=L4+pjLiSvjnzZNj29HK1EPngLEvQU2qJpagOkDJc1cbsL+qtkpvljhqJAjnUk9YZKE QxmpOmmsQ0UvaZAR7i/1f7PtxGnmu8tetTMb1zXTBeGyKkIjzvf4/UPSNfVhkq9AN6Xd dmD+JCJ/8awA1ku2Zos6IPB3YkkT2blmn8y/r7Qu+GxGhjyQKXmDoqLeW0pIxuJlw9kb +RYwT+XbKFhn9NHcp7bJjt1PEHaG0yrEsOCvQFuzcNQYpfWTt23YeVdDa133j6nvw+Yd ygC/yr6YMHEqt9pWUPjodApZr0qZA42jJ81zisgH/KgakdX9HKq0a1giM5NN6qELqkFs 0Ptg== X-Forwarded-Encrypted: i=1; AJvYcCXNwx7DFlajrTcmy/dJcqdllBDk9FOHO+AnSexdeKBhcUgtM620ANaPkH0xhmLIwaOHHRVq6dW4rYzlakA=@vger.kernel.org X-Gm-Message-State: AOJu0YxaHmZBd+J1yHcxLB4bmfINTtFwY3TFmT4LTymSF5V5Iv1G6tYI VEE2zSYIIfgvZo+/Zu+/Lg2fFnADQ6JV9U0R2hbKN/8rKmTedCJYT2iDxCyqhls= X-Gm-Gg: ASbGncs3us3Qc4NRHgV8R6ibqp6bQxjjZ/VHlwd6NMg3UJdfUhN6QoBpSaV+7XFlToM ozxb29ofOCI2acSlfHQcDWXdwvXNy8wPWd71lOScTcHGE6xEVF0jlZ8dHmQA3gE0gpX+Nl6/Xvm mThIfnP20iq4EeyWkx8dSeE66xVQ1yyGub8uSxkWJmYps2J1c3NVTkXFbKfbf+6LpfMBo1zbEJY 6KSbmuBFExWd4miOdHuX/2vdXFmee7UAypZRX8Bd6wsZNv6PKMrhF7VK7ayNKlF9RBDhk5KyHZh R+7ZM7y2vE4UHGhZcebNQRZrSVqQOqEhS3sLGG0= X-Google-Smtp-Source: AGHT+IFyAtiDuay7n/TNXk4xGFEnbFli7K8y/fsUcIy3MBXe0aPAer6QiqYaIaBstZCBK0bISZitEw== X-Received: by 2002:a05:622a:34c:b0:466:8c53:7758 with SMTP id d75a77b69052e-46c70fd31b0mr423868141cf.5.1736907819935; Tue, 14 Jan 2025 18:23:39 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-173-79-56-208.washdc.fios.verizon.net. [173.79.56.208]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-46c873216d0sm59635911cf.12.2025.01.14.18.23.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 18:23:39 -0800 (PST) Date: Tue, 14 Jan 2025 21:23:36 -0500 From: Gregory Price To: "Fabio M. De Francesco" Cc: Davidlohr Bueso , Jonathan Cameron , Dave Jiang , Alison Schofield , Vishal Verma , Ira Weiny , Dan Williams , Robert Richter , ming.li@zohomail.com, linux-kernel@vger.kernel.org, linux-cxl@vger.kernel.org Subject: Re: [PATCH 2/4 v2] cxl/core: Add helpers to detect Low memory Holes on x86 Message-ID: References: <20250114203432.31861-1-fabio.m.de.francesco@linux.intel.com> <20250114203432.31861-3-fabio.m.de.francesco@linux.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=us-ascii Content-Disposition: inline In-Reply-To: <20250114203432.31861-3-fabio.m.de.francesco@linux.intel.com> On Tue, Jan 14, 2025 at 09:32:54PM +0100, Fabio M. De Francesco wrote: > +/* > + * Match CXL Root and Endpoint Decoders by comparing SPA and HPA ranges. > + * > + * On x86, CFMWS ranges never intersect memory holes while endpoint decoders > + * HPA range sizes are always guaranteed aligned to NIW * 256MB; therefore, > + * the given endpoint decoder HPA range size is always expected aligned and > + * also larger than that of the matching root decoder. If there are LMH's, > + * the root decoder range end is always less than SZ_4G. > + */ Is there any reason to limit this memory-hole handling to only low memory holes? I have observed systems where the following memory hole situation occurs: (example, not exact sizes) CFMW1: [ 0xc0000000 - 0xdfffffff ] 512MB range Reserved [ 0xe0000000 - 0xffffffff ] 512MB range CFMW2: [ 0x100000000 - 0x15fffffff ] 1.5GB range 2 CXL Memory Devices w/ 1GB capacity each (again, an example). Note that 1 device has its capacity split across the hole, but if the devices are interleaved then both devices have their capacity split across the hole. It seems with some mild modification, this patch set could be re-used to handle this memory hole scenario as well (w/ addr translation - Robert's patch set) Is there a reason not to handle more than just LMH's in this set? (I may try to hack this up on my test system and report back.) ~Gregory