On Wed, 9 Jul 2025 15:31:14 -0700
<dan.j.williams@xxxxxxxxx> wrote:
> Jonathan Cameron wrote:
> > From: Yicong Yang <yangyicong@xxxxxxxxxxxxx>
> >
> > Extend cpu_cache_invalidate_memregion() to support invalidate certain
> > range of memory. Control of types of invlidation is left for when
>
> s/invlidation/invalidation/
>
> > usecases turn up. For now everything is Clean and Invalidate.
> >
> > Signed-off-by: Yicong Yang <yangyicong@xxxxxxxxxxxxx>
> > Signed-off-by: Jonathan Cameron <jonathan.cameron@xxxxxxxxxx>
> > ---
> > arch/x86/mm/pat/set_memory.c | 2 +-
> > drivers/cxl/core/region.c | 6 +++++-
> > drivers/nvdimm/region.c | 3 ++-
> > drivers/nvdimm/region_devs.c | 3 ++-
> > include/linux/memregion.h | 8 ++++++--
> > 5 files changed, 16 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> > index 46edc11726b7..8b39aad22458 100644
> > --- a/arch/x86/mm/pat/set_memory.c
> > +++ b/arch/x86/mm/pat/set_memory.c
> > @@ -368,7 +368,7 @@ bool cpu_cache_has_invalidate_memregion(void)
> > }
> > EXPORT_SYMBOL_NS_GPL(cpu_cache_has_invalidate_memregion, "DEVMEM");
> >
> > -int cpu_cache_invalidate_memregion(int res_desc)
> > +int cpu_cache_invalidate_memregion(int res_desc, phys_addr_t start, size_t len)
> > {
> > if (WARN_ON_ONCE(!cpu_cache_has_invalidate_memregion()))
> > return -ENXIO;
> > diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> > index 6e5e1460068d..6e6e8ace0897 100644
> > --- a/drivers/cxl/core/region.c
> > +++ b/drivers/cxl/core/region.c
> > @@ -237,7 +237,11 @@ static int cxl_region_invalidate_memregion(struct cxl_region *cxlr)
> > return -ENXIO;
> > }
> >
> > - cpu_cache_invalidate_memregion(IORES_DESC_CXL);
> > + if (!cxlr->params.res)
> > + return -ENXIO;
> > + cpu_cache_invalidate_memregion(IORES_DESC_CXL,
> > + cxlr->params.res->start,
> > + resource_size(cxlr->params.res));
>
> So lets abandon the never used @res_desc argument. It was originally
> there for documentation and the idea that with HDM-DB CXL invalidation
> could be triggered from the device. However, that never came to pass,
> and the continued existence of the option is confusing especially if
> the range may not be a strict subset of the res_desc.
>
> Alternatively, keep the @res_desc parameter and have the backend lookup
> the ranges to flush from the descriptor, but I like that option less.
>
I'll do that as a precursor so we can keep the discussion of that
vs the range being added separate.
Jonathan
