> I think an address space needs a memory region, not a memdev. > Initialize a container region with memory_region_init() > We could then add the two memdev associated regions (with different > attributes) as subregions using memory_region_add_subregion() > > Similar is done for the system memory > https://elixir.bootlin.com/qemu/latest/source/softmmu/physmem.c#L2675 > creates it. Then it's mostly accessed by get_system_memory() > > Memory is then added to that at particular base addresses via for example > https://elixir.bootlin.com/qemu/latest/source/hw/arm/virt.c#L2210 > and similar. > I think we can do the same here. >
Ah, I'm just confused then, this seems reasonable > Curious question on this lot. How are you testing it? Some exciting scripts > to bring the hdm decoders up etc for the volatile region? Or some prototype > driver code? Unfortunately I got pulled off this work for a bit to handle something more pressing. I have only tested that the existing functionality (persistent mode) works as intended, and that at least the ndctl/cxl tools report capacity as expected. As of right now there is no code in the driver to actually touch these regions in a way that works to be able to online these volatile regions - at least so far as I know. I don't remember where I left off, but some pmem-to-ram tutorials online suggest you could online pmem regions like this cxl create-region -d decoder0.0 -m mem0 echo offline > /sys/devices/system/memory/auto_online_blocks ndctl create-namespace -f --mode devdax --continue daxctl enable-device [device name] daxctl reconfigure-device --mode=system-ram all However I don't think this is successful in creating the dax devices, and therefore the reconfiguring into ram.
