From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) (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 45A593816E9 for ; Mon, 2 Feb 2026 17:41:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770054096; cv=none; b=HAJMuLZ75Nf297s4931wFwcHBxnaC9A4o3+3bjLriL5obFNmUMxd/7thLjRWIHtwZO0VhtsXyYKKX7BG3PFAoZEdj4P/WVAm5R4N5gx2c/Fz1RGs5FGi+jHxra6ON7084q6X4EEIbGVk0+B31AjlZrgNEh4F5OH0Wf6rsiUVz/A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770054096; c=relaxed/simple; bh=NvSchrP/3iqVAPZQcFrmz3WZ5MlQLRFV2NZ/1rw7880=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TBUscuQKW34Wrabq0mza6nHm824D1QcnztTGQk+3rDyPZHOTCNiPywZhnu9N4NUjYd4v/mT7iZ8318+7uS73YZDmkMB6837iQjDbCE1eutbGpS++97ypDu0Ma3Jx2jU/gKbqR1OeSIH8qeiiTCjfaj5WM2ZFDH8QcJg7t/HI8Ec= 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=Sx5Ofipm; arc=none smtp.client-ip=209.85.219.49 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="Sx5Ofipm" Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-894774491deso60376226d6.2 for ; Mon, 02 Feb 2026 09:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1770054094; x=1770658894; 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=6OBDEWLEmHCzYPUVrTciErMQbNpqUwuoibpvHtq101E=; b=Sx5OfipmZy6VSguN3UfYogDNou/OpbG+PH0pl1nyOXT/V88T3HqakBgwdFYC+dChwy KrfUKFMnK+VPp7SscQaJqHz4Y1qi1pb+EvNbv1A1I5UJQHVApan8h2NlPs3kwrOopt7r y4Lw6oGg2jS1pmfG6ekVvTRmo1L8kOib4WH3udiGLUpqz4qCYg1VIrNNkZTKubhK3gpn Gqb3MfSjSna1InoYN45/s0i9wis222PsHOK/zHXWJ/1KC87XnaGFrbkvmpO9/P7YEWQp YWEWbmhF3jHygOmg1Fc0fuEVSOIRe+4Brv/7e6Hn1ooqZ8FZV4enITWnxGAtd7lEOO37 04dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770054094; x=1770658894; h=in-reply-to: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=6OBDEWLEmHCzYPUVrTciErMQbNpqUwuoibpvHtq101E=; b=NyvDHYXObRMocTMY1SJC95MAl4sYfHvLNkqdtDLkKbJXGS6EeWDgfiPsINQouRtut+ 69AF7Ju/FeuRJa8RHgeCAhRklFaI1hf8g2en52Rlp+EptCcAK9zf0kPqanPDs7r66KGK I9KNhqrZ+mjCcLOo6fV/DJM8VdPHOOn8QgDya9vPA+ISVTEtT5LQtlva8Fwx7ZztldxR nTKYaBHGPKIn+03JSTQYz7FTR0Hc+M3NheSi0nSBtm3LkqZMubQCmrx3wmYrltKoICKV ZvQQHUcIPK2RJQi63mpJhGpkTdNEuJeqWKSRQKGDhApj+9LibpwWvA0ptlEVCAc44BJU CwHA== X-Forwarded-Encrypted: i=1; AJvYcCUEGwv+UIDwoEnRYkhQqlM8YrB8xCEowSskJP1UbKUxRyrIL3MGrdyxdbndTWg+UYh4g0kgaV3Grx5xHrI=@vger.kernel.org X-Gm-Message-State: AOJu0Yxi3UwvRokiQYqSY+tb17J6ELsCmJ9W/OBCI08iwTCDv3cTatcq DiDdj8QVYqoKnfh5sQASRjuF9VQk1vv0C5SFj+4vhD/Ht1PTs0tL36XcLu5/VxyVCwM= X-Gm-Gg: AZuq6aLSWwj+ZcTW75288e6D2k74RERCr8M3kVU2IcAUJdZ66hcRHGFnKWXgWNEskgs puXUit50UxVfdvvt9Ay4SB/WbWLuxMs2DrvyJKZGrEUDKUnmzSPfts8pSWV31CdNKPGM0+I3SPT h6zOPs6Pz5JXHs0YOpgISCmozFSjwgBOgi+N4QMDEbWvDsdcFRHpEFT+1BusyELgDSkUGN3idV+ 8+ig9Pvzq+vO7wwDxldJOq9PCHCWuCHL2l6OzK1tyjhYS8N8wNuMDQwhYHpNCD4zJvKPS2wBg7m 7jUuhW3Mi+FpA5PryuQjbbAEnm5JPiuw+eQKD509zPYFchnChp/6PwvOwI0AURP1J2T59L25K3U 2KZT+VoU/pjYoGhJof9b3j87qcQVYbykEml4qGngkxar9s+b2QWDzyfhAr/jfFjygNNI07a6ueM CXaFk1mdu3naNFDXmt4Ea3P0Po3IKl4sI5MnDJYC6lzOQBc/gGEdZ9Zr+tSARRX9mB9l4WUBihY f1gOWuE X-Received: by 2002:a05:6214:20ae:b0:894:7fa3:7a32 with SMTP id 6a1803df08f44-894ea0f90c0mr191291886d6.68.1770054094267; Mon, 02 Feb 2026 09:41:34 -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-8c711b7c789sm1274632885a.7.2026.02.02.09.41.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 Feb 2026 09:41:33 -0800 (PST) Date: Mon, 2 Feb 2026 12:41:31 -0500 From: Gregory Price To: "Cheatham, Benjamin" Cc: linux-mm@kvack.org, linux-cxl@vger.kernel.org, nvdimm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kernel-team@meta.com, dave@stgolabs.net, jonathan.cameron@huawei.com, dave.jiang@intel.com, alison.schofield@intel.com, vishal.l.verma@intel.com, ira.weiny@intel.com, dan.j.williams@intel.com, willy@infradead.org, jack@suse.cz, terry.bowman@amd.com, john@jagalactic.com Subject: Re: [PATCH 8/9] cxl/core: Add dax_kmem_region and sysram_region drivers Message-ID: References: <20260129210442.3951412-1-gourry@gourry.net> <20260129210442.3951412-9-gourry@gourry.net> <9652a424-6eb1-462f-8cbd-181af880f98b@amd.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: <9652a424-6eb1-462f-8cbd-181af880f98b@amd.com> On Mon, Feb 02, 2026 at 11:02:37AM -0600, Cheatham, Benjamin wrote: > > > > For auto-regions: > > region_probe() eats it and you get the default behavior. > > > > For non-auto regions: > > create_x_region generates an un-configured region and fails to probe > > until the user commits it and probes it. > > I think this was the source of my misunderstanding. I was trying to understand how it > works for auto regions when it's never meant to apply to them. > > Sorry if this is a stupid question, but what stops auto regions from binding to the > sysram/dax region drivers? They all bind to region devices, so I assume there's something > keeping them from binding before the core region driver gets a chance. > Auto regions explicitly use the dax_kmem path (all existing code, unchanged)- which auto-plugs into dax/hotplug. I do get what you're saying that everything binds on a region type, I will look a little closer at this and see if there's something more reasonable we can do. I think i can update `region/bind` to use the sysram driver with online_type=mhp_default_online_type so you'd end up with effective the auto-region logic: cxlcli create-region -m ram ... existing argument set ------ echo region0 > create_ram_region /* program decoders */ echo region0 > region/bind /* * region_bind(): * 1) alloc sysram_region object * 2) sysram_regionN->online_type=mhp_default_online_type() * 3) add device to bus * 4) device auto-probes all the way down to dax * 5) dax auto-onlines with system default setting */ ------ and Non-auto-region logic (approximation) cxlcli creation-region -m ram --type sysram --online-type=movable ----- echo region0 > create_ram_region /* program decoders */ echo region0 > sysram/bind echo online_movable > sysram_region0/online_type echo sysram_region0 > dax_kmem/bind ----- I want to retain the dax_kmem driver because there may be multiple users other than sysram. For example, a compressed memory region wants to utilize dax_kmem, but has its own complex policy (via N_MEMORY_PRIVATE) so it doesn't want to abstract through sysram_region, but it does want to abstract through dax_kmem. weeeee "software defined memory" weeeee ~Gregory