From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f180.google.com (mail-dy1-f180.google.com [74.125.82.180]) (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 07D4921255A for ; Fri, 24 Apr 2026 06:34:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777012487; cv=none; b=ftb29sG4xy0xAZAroKbdgFSg42UrYHWDS2G2275WrhJWtf2JATpTC3+1nxkOahFIy99djlxn+h7uKZ727aYcq14RaOILi9ls1IW/q/mly8taP/nh2pT1k/R68QiN/h/aXZTK5MbXyGfyMuOK+6L3LJ2ixBEsZrBF6E3u9R46FhU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777012487; c=relaxed/simple; bh=jgiJ3Y2SlkV9kwNakc1V6gDpr64iT7Y2FyUL/UeCM/M=; h=From:Date:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=N0NVyRjBzwXx/mmK8oj0HxfQDjUPEsflzIBBVMXaQs8ixWVyMZU2Vbm+qzCvFSMVOoHg6Oc2AsESn8T9fSm5qRcRaSQyMQDZZ4/iJIyynixc/VjjeBbSmPl8UhJ50nH/SnoZqAHpnu2HxB3ImZiDL14WXpzmJ+ezTdBcJ6d7YB8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=qHRavv2m; arc=none smtp.client-ip=74.125.82.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qHRavv2m" Received: by mail-dy1-f180.google.com with SMTP id 5a478bee46e88-2d9916deb14so13322922eec.0 for ; Thu, 23 Apr 2026 23:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777012485; x=1777617285; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from:from:to :cc:subject:date:message-id:reply-to; bh=CjqjMDSnQiv+VdsVSEhmqx1RDmYUs+TDJJtITK0bPSw=; b=qHRavv2mXfRlEtdQYEBLCNPTSIemN6HjoqGxslhX6m0//IIdk3Q2XQpzZfVC/Cg4Mj VHZxDYvtMRR8gJnsZZeZSQVJPT/F5gVXmsMq7uckpU6xMeA7UZfOnWsLRm0NaifffAP7 RvZVL+pGI0DdFwk8KEO2orU8hJeNvD1Wiw/ZUv1VSGFLQgmDiH8xyFZEJvqUdYX18qK6 JsxB1M+vR+7/PByHL0rB8SRmDK7Q+V+o46VGuM9y/+oRe7qaptCeJjVg2wIuhjzLInjN dXT/yp7/pnoTOxLJg/e/mwhXape1uwFyuIKS+bR014vHHAaAD4viJijX/g80KkflNXDe zcAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777012485; x=1777617285; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:date:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CjqjMDSnQiv+VdsVSEhmqx1RDmYUs+TDJJtITK0bPSw=; b=JTyQlMuxshhG0XHGwnV6k/6z59f5lcky4Uc2L97LfXoMayoiggawOmqmPGmZXP7i15 YnWXMR5qzlNnF4YPIL4V9pLNuajcbjVfbsu7m3ggn1nh1tCS7lsj8hJZwRUeUU0LrM7d kvlwx6w8mjp53nZkWONwbAsZSQUEed5sac8D5ii1MHj4iKTmUbbLQH6JMx3dQqn7k9/p cRJwgmYkM0EXKfCNTHr1esSDy2BY5MwwZ96808U2j8BRcJQ14JNKKQrAqupxk21SQ6F9 1ojP2In0qUVxhWstnYsics3gyBgUvoOO3ixCemuMfOZk2Z7iefKw9adRFIhYK0uasCTa 4Fyw== X-Forwarded-Encrypted: i=1; AFNElJ8Iv+/Ox8bNss+9M8F+EpZLL3UcRBWtMW+tjYIZksOCp9RhoDsMGOI24/HUcR9QNVcOyR25VcwqcQUVi7E=@vger.kernel.org X-Gm-Message-State: AOJu0Yw046MQJjmAQEOSAZSN28GF1rfXMMuzEjZp2yZb2hbVj+APer5G 8qJpxjLOKOgKudeyX7meIm6kcg5mpOsN4wl6t4W7MRdYcgeIrsEEex7d X-Gm-Gg: AeBDiet/wxgG+cyDsYqnxw9qHiny8VKEQRk20ScdyiGNk/Ad7f+SmPQrbKzDqCiWjFi 23cBA9rpLh0uTQ/KhyYnM1GLjOFbUkYxuLXDLo8qg46F1NQ+iy93yVZoscfYMxm50A0KiL2BLDN gv3RnPA+is3OH+OIc0Z9pOyI09GPly82spGGZ3m72RE/TPt6XDdLscgtardJyjxFy7wyevvJ26U fnEksPl1QnasIgu1fQ9EeyFq2OPQdCHqeCTS/rQV//fkVZL7o0bEfc5knOM1UvWlAsVoIl4i0Bt tl99MeToeezYOKchQsFuGA7pS4Tp2ah3J8onhbeFmpWfatR/BhjPVmSD+felrZDmC6AWZ2Mrk19 wC8KR96yAeiQTGAv6WZ6fUJxX+ssCEy3l4fjBCyqYTUTwlUzSd9LBODANHX1sperKvzelboJhqc C0WrnmXHNnv8ifYEWcFn5rUUpPp27pto9yRmlyz2EQMxYIN8q6O6WvGaiNqKRTIMiMM/u5HooAS 7Rc4RsJEWHWZ6ZIzhsE3zQ= X-Received: by 2002:a05:7300:6c05:b0:2d4:2cc8:67e with SMTP id 5a478bee46e88-2e47a106ccfmr17594838eec.23.1777012484979; Thu, 23 Apr 2026 23:34:44 -0700 (PDT) Received: from 4470NRD-ASU.ssi.samsung.com (c-73-170-217-179.hsd1.ca.comcast.net. [73.170.217.179]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2e53d9b056fsm40279171eec.29.2026.04.23.23.34.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 23:34:44 -0700 (PDT) From: Anisa Su X-Google-Original-From: Anisa Su Date: Thu, 23 Apr 2026 23:34:42 -0700 To: John Groves Cc: Davidlohr Bueso , Jonathan Cameron , Dave Jiang , Alison Schofield , Vishal Verma , Ira Weiny , Dan Williams , John Groves , Fan Ni , Shiju Jose , Robert Richter , "linux-cxl@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "dev.srinivasulu@gmail.com" , "arramesh@micron.com" , "ajayjoshi@micron.com" Subject: Re: [RFC PATCH 0/4] cxl/extent: Enable and validate multi-extent DCDs Message-ID: References: <20260423235108.3732424-1-john@jagalactic.com> <0100019dbcc13648-596853f3-0083-46e0-b654-396eedd657cb-000000@email.amazonses.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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0100019dbcc13648-596853f3-0083-46e0-b654-396eedd657cb-000000@email.amazonses.com> On Thu, Apr 23, 2026 at 11:51:12PM +0000, John Groves wrote: > From: John Groves > > This series fixes correctness issues in the DCD (Dynamic Capacity > Device) add-capacity pipeline so that multi-tag allocations, sharable > CDAT regions, and cross-partition checks work end-to-end. > Thanks for the fixes, this makes way more sense. Let me see if I can squash these nicely before LSFMM :) One question based off the initial read: When we do the actual dax device creation via daxctl create-device, would we want to add an optional arg specifying uuid? I think right now, each region_extent becomes a dax_resource of the sparse dax region and create-device grabs any unused dax_resource if -s isn't specified. So if we want to limit to 1 tagged allocation/DAX device, we would want some way to specify that. But let me double check tomorrow Thanks, Anisa > Base > ---- > > The series applies on top of Anisa Su's DCD stack — specifically the > tip of famfs-v9-dcd on the 'anisa' remote > (git@github.com:anisa-su993/anisa-linux-kernel.git). That stack is > the one posted to linux-cxl here: > > https://lore.kernel.org/linux-cxl/adnWg-60uKmduTsh@gourry-fedora-PF4VCD3F/T/#t > > I started out commenting on prior series, then started modifying it, > before settling on this initial approach of generalizing the > functionality through additional patches. I'm hoping the stake holders > will find this easy to follow - at least as easy to follow as something > this tedious and nuanced can be. > > Also, as one of the authors of the DCD spec: Now I get why this was hard > to follow and implement. The implementation is pretty complicated. > > Note that this RFC builds happily, but I have not tested it yet. This > exercise has been about fleshing out the full logic. > > The patches > ----------- > > 1) cxl/extent: Promote cxlr_dax->region_extent to an xarray > > Infrastructure only. Replaces the single-slot region_extent > pointer on struct cxl_dax_region with an xarray keyed by an > allocator-assigned u32. No behavior change; prepares storage for > multiple tagged allocations per DAX-region shim. > > 2) cxl/extent: Fix DCD add-capacity: per-tag assembly, ordering, and > integrity > > Rewrites the add-capacity pipeline around the tag as the unit of > allocation (not the More-chain). Drops the DPA-contiguity reject, > assembles each tag group separately, stable-sorts by > shared_extn_seq, and adds cross-More-chain uniqueness, > sequence-integrity, and alignment gates. Lifts the single-slot > "already onlined" gate now that (1) is in place. > > 3) cxl/extent: Support extents in sharable CDAT regions > > Drops the per-extent rejection of shared_extn_seq != 0 and > replaces it with a partition-aware check driven by the DSMAS > SHAREABLE bit already exposed through cxl_dpa_partition. > > 4) cxl/extent: Reject tagged extents that span DC partitions > > Adds a group-level check rejecting tagged allocations whose > extents resolve to different DC partitions. A single host-visible > allocation cannot meaningfully straddle partitions whose CDAT > attributes disagree. > > Signed-off-by: John Groves > > John Groves (4): > cxl/extent: Promote cxlr_dax->region_extent to an xarray > cxl/extent: Fix DCD add-capacity: per-tag assembly, ordering, and > integrity > cxl/extent: Support extents in sharable CDAT regions > cxl/extent: Reject tagged extents that span DC partitions > > drivers/cxl/core/extent.c | 93 +++--- > drivers/cxl/core/mbox.c | 628 +++++++++++++++++++++++++++++++------- > drivers/cxl/core/region.c | 2 + > drivers/cxl/cxl.h | 9 +- > include/cxl/event.h | 1 - > 5 files changed, 584 insertions(+), 149 deletions(-) > > -- > 2.53.0 > >