Re: [PATCH] hw/mem: support zero memory size CXL device

[Gregory Price <gourry@gourry.net>]

On Tue, Dec 24, 2024 at 03:13:15PM +0000, Jonathan Cameron wrote:
> On Tue, 10 Dec 2024 14:13:29 -0500
> Gregory Price <gourry@gourry.net> wrote:
> 
> > On Tue, Dec 03, 2024 at 09:15:51PM +0000, Hongjian Fan wrote:
> > > Hi Jonathan,
> > > 
> > > I'm trying to emulate our memory appliance which is similar to a MH-SLD. The memory device is connected to the host server while the size of the memory could be changed by the out-of-band fabric manager. If there is no memory assigned to the host, the CXL device will be booted as zero memory size.  
> > 
> > This should not be how this is done.
> Agreed, but...
> 
> It sounds like a pre DCD boot time only pooling solution?
> 
> What is the path to adding memory?
>
> > 
> > The ACPI tables should report the maximum possible size, and the DCD
> > infrastructure should enable physical regions that have been added to the host.
> > 
> This isn't the ACPI bit, it's just the device reporting.  Can have a huge
> CFMWS and tiny devices.
> 

If the device is booted as a 0-memory device, how is the CFMWS populated
with the capacity needed to back it? It's all coming from the same
tables.

You poked the right spot in their post - we need more information about
how the memory is added.

If the intent is to just increase/decrease the capacity of the device
on the surface, then the only method I can see here is "tear the device
device down and re-initialize it". At least then - I think? - the driver
will go off and create the appropriate resources.  I've played with this
in QEMU previously in the past, so I *think* that works?

If it doesn't do that, then they'll need to go off and basically
re-invent DCD for their device in the driver (or via fwctl? yikes).



Side note, after thinking about it: a 0-memory device at least lets you
poke all the control bits without having to care about the actual memory
piece, so maybe that's useful regardless.

~Gregory