[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC v4 3/3] hw/cxl: Multi-Region CXL Type-3 Devices (Volatile and P
From: |
Gregory Price |
Subject: |
Re: [RFC v4 3/3] hw/cxl: Multi-Region CXL Type-3 Devices (Volatile and Persistent) |
Date: |
Mon, 19 Dec 2022 12:55:44 -0500 |
> 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.