On 1/27/2026 1:59 PM, [email protected] wrote:
Smita Koralahalli wrote:
Add a helper to determine whether a given Soft Reserved memory range is
fully contained within the committed CXL region.
This helper provides a primitive for policy decisions in subsequent
patches such as co-ordination with dax_hmem to determine whether CXL has
fully claimed ownership of Soft Reserved memory ranges.
No functional changes are introduced by this patch.
Signed-off-by: Smita Koralahalli <[email protected]>
---
drivers/cxl/core/region.c | 29 +++++++++++++++++++++++++++++
drivers/cxl/cxl.h | 5 +++++
2 files changed, 34 insertions(+)
diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
index 45ee598daf95..9827a6dd3187 100644
--- a/drivers/cxl/core/region.c
+++ b/drivers/cxl/core/region.c
@@ -3875,6 +3875,35 @@ static int cxl_region_debugfs_poison_clear(void *data,
u64 offset)
DEFINE_DEBUGFS_ATTRIBUTE(cxl_poison_clear_fops, NULL,
cxl_region_debugfs_poison_clear, "%llx\n");
+static int cxl_region_contains_sr_cb(struct device *dev, void *data)
+{
+ struct resource *res = data;
+ struct cxl_region *cxlr;
+ struct cxl_region_params *p;
+
+ if (!is_cxl_region(dev))
+ return 0;
+
+ cxlr = to_cxl_region(dev);
+ p = &cxlr->params;
+
+ if (p->state != CXL_CONFIG_COMMIT)
+ return 0;
+
+ if (!p->res)
+ return 0;
+
+ return resource_contains(p->res, res) ? 1 : 0;
I suspect this is too precise and this should instead be
resource_overlaps(). Because, in the case where the platform is taking
liberties with the specification, there is a high likelihood that
driver's view of the region does not neatly contain the range published
in the memory map.
There is also the problem with the fact that firmware does not
necessarily need to split memory map entries on region boundaries. That
gets slightly better if this @res argument is the range boundary that
has been adjusted by HMAT, but still not a guarantee per the spec.
Hmm, My reading of your earlier guidance was that this logic is meant to
be coarse, and is acceptable to fall back to HMEM if firmware
descriptions don’t line up cleanly.
If firmware takes liberties and publishes ranges that don’t neatly
contain inside a committed region resource, my assumption was that
failing the containment check and falling back is acceptable.
However, given that the SR ranges HMEM walks are already filtered by
ACPI HMAT, and that there is a relatively low likelihood that a single
HMAT range spans multiple committed CXL regions, it would be sufficient
to treat any overlap with a committed region as acceptable?
If so, the description in patch 6 should also be updated accordingly,
the wording around fully contained would need to be relaxed to reflect
overlap rather than strict containment.
+}
+
+bool cxl_region_contains_soft_reserve(const struct resource *res)
+{
+ guard(rwsem_read)(&cxl_rwsem.region);
+ return bus_for_each_dev(&cxl_bus_type, NULL, (void *)res,
No, need to cast pointers to 'void *'.
Okay.
Thanks
Smita
