Koralahalli Channabasappa, Smita wrote: [..] > > 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?
Oh, am I reading the polarity wrong...? /me reads patch 6. Yes, I was missing that cxl_contains_soft_reserve() is doing an "overlap" check and then cxl_region_contains_soft_reserve() is making sure it lines up exactly. So yes, the way you have it matches what I expected and I was confused reading patch 4 in isolation. I think cxl_contains_soft_reserve() might want to be named differently since it is validating that any overlap is precisely contained. Perhaps soft_reserve_has_cxl_match()?
