On Wed, Feb 04, 2026 at 11:57:34AM -0600, Ira Weiny wrote:
> Gregory Price wrote:
>
> TLDR; I just don't want to see an explosion of 'drivers' for various
> 'policies'. I think your use of the word 'policy' triggered me.
>
Gotcha. Yeah words are hard. I'm not sure what to call the difference
between the dax pattern and the sysram pattern... workflow?
You're *kind of* encoding "a policy", but more like defining a workflow
i guess. I suppose i'll update to that terminology unless someone has
something better.
> > - sysram : preferably doing direct hotplug - not via dax
> > private-ram may re-use this cleanly with some config bits
>
> Pre-reading this entire email I think what I was thinking was bundling a
> lot of this in here. Put knobs here to control 'policy' not add to this
> list for more policies.
>
yup, so you have some sysram_region/ specific knobs
sysram_region0/online_type
sysram_region0/extents/[A,B,C]
> >
> >
... snipping out virtio stuff until the end ...
>
> But for sysram. No. It is easy enough to assign a tag to the region and
> any extent which shows up without that tag (be it NULL tag or tag A) gets
> rejected. All valid tagged extents get hot plugged.
>
> Simple. Easy policy for user space to control.
>
Of what use is a tag for a sysram region?
The HPA is effectively a tag in this case.
An HPA can only belong to one region.
> >
> > I would need to think this over a bit more, I'm not quite seeing how
> > what you are suggesting would work.
>
> I think you set it out above. I thought the sysram driver would have a
> control for N_MEMORY_PRIVATE vs N_MEMORY which could control that policy
> during hotplug. Maybe I'm hallucinating.
>
I imagine a device driver setting up a sysram_region with a private bit
before it goes to hotplug.
this would dictate whether it called
add_memory_driver_managed() or
add_private_memory_driver_managed()
so like
my_driver_code:
sysram = create_sysram_region(...);
sysram.private_callbacks = my_driver_callbacks;
... continue with the rest of configuration ...
probe(sysram); /* sysram does the registration */
Since private-memory users actually have *device-defined* POLICY (yes,
policy) of some kind, I can imagine those devices needing to provide
drivers that set up that policy.
example: compressed memory devices may want to be on a demote-only node
and control page-table mappings to enforce Read-Only.
(note: don't get hung-up on callbacks, design here is not set, just
things floating around)
But in the short term, we should try to design it such that additional
drivers are not needed where reasonable.
I can imagine this showing up as needing mm/cram.c and registering a
compressed-node with mm/cram.c rather than enabling driver callbacks
(i'm learning callbacks are a mess, and going to try to avoid it).
> Summary, it is fine to add new knobs to the sysram driver for new policy
> controls. It is _not_ ok to have to put in a new driver.
>
Well, we don't have a sysram driver at the moment :P
We have a region driver :]
We should have a sysram driver and split up the workflows between dax
and sysram.
> I'm not clear if sysram could be used for virtio, or even needed. I'm
> still figuring out how virtio of simple memory devices is a gain.
>
Jonathan mentioned that he thinks it would be possible to just bring it
online as a private-node and inform the consumer of this. I think
that's probably reasonable.
~Gregory
