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
