Re: [PATCH 3/8] mm/memory_hotplug: add APIs for explicit online type control

[Gregory Price <gourry@gourry.net>]

On Wed, Jan 14, 2026 at 11:21:34AM +0100, David Hildenbrand (Red Hat) wrote:
> On 1/14/26 09:51, Gregory Price wrote:
> > Add new memory hotplug APIs that allow callers to explicitly control
> > the online type when adding or managing memory:
> > 
> >    - Extend add_memory_driver_managed() with an online_type parameter:
> >      Callers can now specify MMOP_ONLINE, MMOP_ONLINE_KERNEL, or
> >      MMOP_ONLINE_MOVABLE to online with that type, MMOP_OFFLINE to leave
> >      memory offline, or MMOP_SYSTEM_DEFAULT to use the system default
> >      policy. Update virtio_mem to pass MMOP_SYSTEM_DEFAULT to maintain
> >      existing behavior.
> 
> I wonder if we rather want to add a new interface
> (add_and_online_memory_driver_managed()) where we can restrict it to known
> kernel modules that do not violate user-space onlining policies.
> 

I originally did this, but then add_memory_driver_managed is just

__add_memory_driver_managed(..., MMOP_SYSTEM_DEFAULT)

at that point, just update all the existing callers of
add_memory_driver_managed(..., mhp_default_etc) and make it explicit in
those call spaces that this is what's happening.

> For dax we know that user space will define the policy.
> 

Actually this may not always be true.  A driver spawning a dax on probe
might also end up selecting the policy... eventually... maybe... I might
be planning to add that glue between CXL and DAX so I can add some
config similar to the system-default policy to avoid systems with
multiple memory-devices being forced into the same policy

(e.g. CXL memory device can online auto in ZONE_MOVABLE, but the other
 device can have its own policy).

There's a weird corner case for CXL auto-regions (BIOS configured
everything but left the memory EFI_MEMORY_SP - so comes up as DAX).
I'm trying to keep those systems working the same as they have been
while the userland policy stuff catches up.  Early CXL patterns are :[

> > 
> >    - online_memory_range(): online a previously-added memory range with
> >      a specified online type (MMOP_ONLINE, MMOP_ONLINE_KERNEL, or
> >      MMOP_ONLINE_MOVABLE). Validates that the type is valid for onlining.
> 
> Why not simply online_memory() and offline_memory() ?
> 

stupidly: I thought online_memory existed lol, ack.

> > 
> >    - offline_memory(): offline a memory range without removing it. This
> >      is a wrapper around the internal __offline_memory() that handles
> >      locking. Useful for drivers that want to offline memory blocks
> >      before performing other operations.
> > 
> 
> These two should be not exported to arbitrary kernel modules. Use
> EXPORT_SYMBOL_FOR_MODULES() if required, or do not export them at all.
> 

hm, not sure i understand this.  Maybe you address their usage later in
dax_kmem_do_online and dax_kmem_do_offline, i'll come back around on
this.

I did see you were asking about why we need the offline state.  I'll
come back to it there.

> > diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> > index d5407264d72a..0f98bea6da65 100644
> > --- a/include/linux/memory_hotplug.h
> > +++ b/include/linux/memory_hotplug.h
> > @@ -265,6 +265,7 @@ static inline void pgdat_resize_init(struct pglist_data *pgdat) {}
> >   extern void try_offline_node(int nid);
> >   extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages,
> >   			 struct zone *zone, struct memory_group *group);
> > +extern int offline_memory(u64 start, u64 size);
> 
> No new "extern" for functions.
> 

doh, habit matching surrounding code

> > index ab73c8fcc0f1..515ff9d18039 100644
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -1343,6 +1343,34 @@ static int online_memory_block(struct memory_block *mem, void *arg)
> >   	return device_online(&mem->dev);
> >   }
> > +/**
> > + * online_memory_range - online memory blocks in a range
> > + * @start: physical start address of memory region
> > + * @size: size of memory region
> > + * @online_type: MMOP_ONLINE, MMOP_ONLINE_KERNEL, or MMOP_ONLINE_MOVABLE
> 
> I wonder if we instead want something that consumes all parameters like
> 
> int online_or_offline_memory(int online_type)
> 
> Then it's easier to use and we don't really have to document the
> "online_type" that much to hand-select some values.
> 
> (I'm sure there are better nameing suggestions :) )
> 

mhp_do_the_thing(int online_type) :P

I can think about this.

> Should we document what happens if the memory is already online, but was
> onlined to a different zone?
> 

Yeah i'll do that, it should just refuse, since that's what dax does.

> > + *
> > + * @online_type specifies the online behavior: MMOP_ONLINE, MMOP_ONLINE_KERNEL,
> > + * MMOP_ONLINE_MOVABLE to online with that type, MMOP_OFFLINE to leave offline,
> > + * or MMOP_SYSTEM_DEFAULT to use the system default policy.
> > + *
> 
> I think we can simplify this documentation. Especially, one
> MMOP_SYSTEM_DEFAULT is gone.
>

ack

> > +/*
> > + * Try to offline a memory range. Might take a long time to finish in case
> > + * memory is still in use. In case of failure, already offlined memory blocks
> > + * will be re-onlined.
> > + */
> 
> Proper kerneldoc? :)
>

ack

~Gregory