From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) (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 DBA942BE05E for ; Mon, 12 Jan 2026 22:44:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768257843; cv=none; b=h+D5ACzNf2Qypws9vLmvW2Uuw9MdxW+W4jSe4FuEwStqeBLE0i1CpwcBcbFKEjOqvce7ukvRMcV4gZlMqVuP64KEzpIqDXMzvihqCjqDGl60zdUm7/IsIt2rq3os4BMVPaBqLqLW69Ex/p9VYpDRZmAYSJEqfUuHukVA0m3AzWo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768257843; c=relaxed/simple; bh=g1R9ylICbqoyRRxYcuZbIs5wPX4pOd2UUJ9XQ6qoGS4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dKb4j2A/cqTXc1A0GHG73hFokQHW6a1lM2tJpc5eyXwX2GWDA9UDq5fpBRnf+6yJjqGRidWBI6toDxNNgQgE7vpHrYSXb6xb9tsJDg24FuyWiUI+gy5sBAk1NUmOTUu48liHNBLBZB4LGCqp01viOluWL2slStCdPbRo4bwCJpM= 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=t7jBElX0; arc=none smtp.client-ip=209.85.222.182 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="t7jBElX0" Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-8c15e8b2f1aso713785685a.0 for ; Mon, 12 Jan 2026 14:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1768257841; x=1768862641; 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=QH8QtdWievukF51h7NvNfF87uO9BA61HaSXBOWn3Ngg=; b=t7jBElX0H9BJBPG9yerpNOc73YyxE1IenKBad+8GIT+HVIkDnzEEY8nvNhQvSMtqp4 KCpNxnJhJYfYmgPhqBDa49es07jGYc+OyhwIGk7/NuLTRuaKQoLkOQC/2NifH+frNscm jm78iTARGkvKf1uL3b4zTzFzvTPaQqIia1Jb4z0nHf54Z9bfvMXImnPK7PoDLT1LNRqS uvbuvH6MJWX2sCEwsfw2sli2XNS8lHEFpDKt36eQhpl3uFdBuKcZTfTQxhgkMe5NChhD wD0Hj4Fqh57Jjcmn6rjIgioKH/ct9Wj6ZA1InMCU8mrT9OodmfYBIHCx1QpVCB/sQDAT l3Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768257841; x=1768862641; 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=QH8QtdWievukF51h7NvNfF87uO9BA61HaSXBOWn3Ngg=; b=alfMqi1Mb2OLFHM22NieXpARQsgV2APdFGtrVC9TmwBH2RbZH8NzwSDszQxoCgByWE TwFfc3h23dogX7gkmtv4bIEZMFfP1mE24TldBhsSFhKAa1vJAsRt5f1O8Y1vazvFZtxT RYtCtdbE7rzT3hgMtHt5NEAz561eJIMHhKGSJfuoz35le/194H5cB8TdxFhLFqkpwURY 14Kf3yXh3kgUQm5LAR8CK/lvHfnK6SwQ+NJyVFjWnXvJaDf/Bz5jtC4OMam0qjAJ4p/x n056MhjKIuo/hYyES6073rrRPamY54SQszPlvplVdZp23G5wyvA0ok+wkIbsw/Zh2uJ5 V5YQ== X-Forwarded-Encrypted: i=1; AJvYcCUnn4WDqrmHVe9VOrFaMKWSaDE6wEKJVLsinvAmwpuxE7H7FyW6Gy08iZV+rYGZpkxP6n+razAtKZEvdeU=@vger.kernel.org X-Gm-Message-State: AOJu0YyYvAuxk4jcUXW5bU1GAkD5q0kjUpKQhaHKCfdUjH9H0DxTf94Z 0H5h48+4pFj1jfiYKqWdeq5hPjPthQTW3fFeg7dp1AOSZycr+rl7a6OCLn1dhb8pAX8= X-Gm-Gg: AY/fxX6Akxqo/HkeUD07lSmxB6p28Womm9EGMGNayEpI4QRyN/zOPIUrZRYt7oyknQg oB5iH0Xu68TqTBTTRYEKjmwgPjgYqBuD7Krd/rE5HvqMxNudhlndWVfLI5PMQf8mfFIGUTMqySU NNi8nRWtXWmSDDtVURf2A5UaHmiJHLYVy9+CQPF1NTrOTaLBO1elaCQjWz4Z82yd10nuA92O/UT ChasFbCk0eiqPrrLB3QQnzobUQUq6wH6uBVnu4JbTIlKZz1FD8poUN354LDoBEt3SuGZhLKw39q nQIC8XEsXyiYnhkCbX8KlGXJBhMZK8ilt8mGFRrQKyzTenaE/icbR9GjIQB9VqkJiWcCF6KBg/8 FV2p9aF49OaNWuixAR1FdDRq7Bm5uVVdtCpD3GjOKBmKjeHkSLD+bTaY52PoZVLrgxI//AH2SZH +epMELLEMOFTZqxbdnqWGv84DMVL7SH5r0/fUOMlwB51d0Wwj4mGB27rJrlwIVHszUgM2+VMhkj Y6urjrz X-Google-Smtp-Source: AGHT+IFNRFsCye/L0TjmYzMj9slskh69Z6egn+dOxFWH73HuXbt8paZZikjzfT3XP/huGZSAVHaypA== X-Received: by 2002:a05:620a:1791:b0:8b1:b2ed:2735 with SMTP id af79cd13be357-8c389407c32mr2540922685a.46.1768257840841; Mon, 12 Jan 2026 14:44:00 -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-8c37f5438f6sm1568702285a.53.2026.01.12.14.43.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 14:44:00 -0800 (PST) Date: Mon, 12 Jan 2026 17:43:27 -0500 From: Gregory Price To: "David Hildenbrand (Red Hat)" Cc: linux-cxl@vger.kernel.org, linux-kernel@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 Subject: Re: [PATCH 2/6] cxl: add sysram_region memory controller Message-ID: References: <20260112163514.2551809-1-gourry@gourry.net> <20260112163514.2551809-3-gourry@gourry.net> <3d5ccbb3-a083-4a5c-8c97-2db2adbc5446@kernel.org> 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: <3d5ccbb3-a083-4a5c-8c97-2db2adbc5446@kernel.org> On Mon, Jan 12, 2026 at 09:00:54PM +0100, David Hildenbrand (Red Hat) wrote: > On 1/12/26 17:35, Gregory Price wrote: > > Add a sysram memctrl that directly hotplugs memory without needing to > > route through DAX. This simplifies the sysram usecase considerably. > > > > The sysram memctl adds new sysfs controls when registered: > > region/memctrl/[hotplug, hotunplug, state] > > > > hotplug: controller attempts to hotplug the memory region > > Why disconnect the hotplug from the online state? > > echo online_movable > hotplug ? > > Then we can just have something like add_and_online_memory() in the core. > mostly i cobbled this together over the weekend to have it for discussion at the community DAX meeting. I think just having [offline,online,online_movable] > hotplug is probably the better option. There's not much use in a memory_region control that lets you offline the memory but not remove the blocks. I mean, I know of *a* use for that, and it's not something we want to support :] > > hotunplug: controller attempts to offline and hotunplug the memory region > > state: [online,online_normal,offline] > > online : controller onlines blocks in ZONE_MOVABLE > > I don't like this incosistency regarding the remainder of common hotplug > toggles. > > We should use exactly the same values with exactly the same semantics. Yes, > user-space tooling should be thaught to pass in online_movable :) > > > online_normal: controller onlines blocks in ZONE_NORMAL > > offline : controller attempts to offline the memory blocks > > Why is that required? ideally we'd start with hotplug vs. hotunplug and > leave manual onlining/offlining out of this interface for now. > That is fair, although i would like a build option to default the online mode to ZONE_MOVABLE for auto-configured sysram regions w/ the SP bit set, otherwise that will be forever locked to using the DAX model. > > + } else if (sysfs_streq(buf, "offline")) { > > + int offline_rc = 0; > > + > > + rc = walk_memory_blocks(range.start, range_len(&range), > > + &offline_rc, offline_memory_block_cb); > > + if (!rc) > > + rc = offline_rc; > > Let's expose this functionality through some common-code helpers. I really > don't want more code doing this non-obvious device_offline() etc dance. > > walk_memory_blocks() should become a core-mm helper. Maybe we can also > cleanup drivers/acpi/acpi_memhotplug.c in that regard. > > Hopefully we can then also reuse these helpers in ppc code (see > dlpar_add_lmb() and dlpar_remove_lmb() that do something similar, but grab > the device hotplug lock themselves as they want to perform some additional > operations). > I'll take a look. Thanks! ~Gregory