Re: [PATCH v9 00/19] DCD: Add support for Dynamic Capacity Devices (DCD)

[Gregory Price <gourry@gourry.net>]

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