From: Jonathan Cameron <Jonathan.Cameron@Huawei.com> To: Gregory Price <gregory.price@memverge.com> Cc: Gregory Price <gourry.memverge@gmail.com>, <qemu-devel@nongnu.org>, <linux-cxl@vger.kernel.org>, <alison.schofield@intel.com>, <dave@stgolabs.net>, <a.manzanares@samsung.com>, <bwidawsk@kernel.org>, <hchkuo@avery-design.com.tw>, <cbrowy@avery-design.com>, <ira.weiny@intel.com> Subject: Re: [RFC v4 3/3] hw/cxl: Multi-Region CXL Type-3 Devices (Volatile and Persistent) Date: Tue, 20 Dec 2022 15:34:53 +0000 [thread overview] Message-ID: <20221220153453.00000436@Huawei.com> (raw) In-Reply-To: <Y6CloIiuruB/h7qp@memverge.com> On Mon, 19 Dec 2022 12:55:44 -0500 Gregory Price <gregory.price@memverge.com> wrote: > > 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. No problem. It happens to us all! > 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. Sure. I only bothered testing the it in some dax modes rather than via kmem. It 'should' work but more testing needed there. However as you've noted, that only applies to the pmem regions at the moment. I wondered if you'd scripted the HDM decoder setup etc for test purposes (so what the driver will do). Alternative to that would be enabling the driver support. Not sure if anyone is looking at that yet. Final alternative would be to port the existing EDK2 based support to work on QEMU. All non trivial jobs so may take a while, Jonathan
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via <qemu-devel@nongnu.org> To: Gregory Price <gregory.price@memverge.com> Cc: Gregory Price <gourry.memverge@gmail.com>, <qemu-devel@nongnu.org>, <linux-cxl@vger.kernel.org>, <alison.schofield@intel.com>, <dave@stgolabs.net>, <a.manzanares@samsung.com>, <bwidawsk@kernel.org>, <hchkuo@avery-design.com.tw>, <cbrowy@avery-design.com>, <ira.weiny@intel.com> Subject: Re: [RFC v4 3/3] hw/cxl: Multi-Region CXL Type-3 Devices (Volatile and Persistent) Date: Tue, 20 Dec 2022 15:34:53 +0000 [thread overview] Message-ID: <20221220153453.00000436@Huawei.com> (raw) In-Reply-To: <Y6CloIiuruB/h7qp@memverge.com> On Mon, 19 Dec 2022 12:55:44 -0500 Gregory Price <gregory.price@memverge.com> wrote: > > 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. No problem. It happens to us all! > 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. Sure. I only bothered testing the it in some dax modes rather than via kmem. It 'should' work but more testing needed there. However as you've noted, that only applies to the pmem regions at the moment. I wondered if you'd scripted the HDM decoder setup etc for test purposes (so what the driver will do). Alternative to that would be enabling the driver support. Not sure if anyone is looking at that yet. Final alternative would be to port the existing EDK2 based support to work on QEMU. All non trivial jobs so may take a while, Jonathan
next prev parent reply other threads:[~2022-12-20 15:35 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-28 15:01 [RFC v4 0/3] CXL Type-3 Volatile Memory Support Gregory Price 2022-11-28 15:01 ` [RFC v4 1/3] hw/cxl: Add CXL_CAPACITY_MULTIPLIER definition Gregory Price 2022-11-28 15:01 ` [RFC v4 2/3] tests/qtest/cxl-test: whitespace, line ending cleanup Gregory Price 2023-01-05 14:38 ` Jonathan Cameron 2023-01-05 14:38 ` Jonathan Cameron via 2023-01-30 13:11 ` Jonathan Cameron 2023-01-30 13:11 ` Jonathan Cameron via 2023-01-30 14:38 ` Gregory Price 2022-11-28 15:01 ` [RFC v4 3/3] hw/cxl: Multi-Region CXL Type-3 Devices (Volatile and Persistent) Gregory Price [not found] ` <CGME20221208225559uscas1p1e9e2c7c8f9a1654a5f41cef2c47859a8@uscas1p1.samsung.com> 2022-12-08 22:55 ` Fan Ni 2022-12-08 23:06 ` Gregory Price 2022-12-19 12:42 ` Jonathan Cameron 2022-12-19 12:42 ` Jonathan Cameron via 2022-12-19 16:12 ` Gregory Price 2022-12-19 17:25 ` Jonathan Cameron via 2022-12-19 17:25 ` Jonathan Cameron 2022-12-19 17:55 ` Gregory Price 2022-12-20 15:34 ` Jonathan Cameron [this message] 2022-12-20 15:34 ` Jonathan Cameron via 2022-12-20 19:27 ` Gregory Price 2023-01-03 15:56 ` Jonathan Cameron 2023-01-03 15:56 ` Jonathan Cameron via 2023-01-03 16:02 ` Gregory Price 2023-01-03 18:15 ` Jonathan Cameron 2023-01-03 18:15 ` Jonathan Cameron via 2023-01-19 17:15 ` Gregory Price 2023-01-19 17:31 ` Jonathan Cameron 2023-01-19 17:31 ` Jonathan Cameron via 2023-01-19 22:13 ` Gregory Price 2023-01-20 10:59 ` Jonathan Cameron 2023-01-20 10:59 ` Jonathan Cameron via 2023-01-30 13:24 ` Jonathan Cameron 2023-01-30 13:24 ` Jonathan Cameron via 2023-01-30 14:37 ` Gregory Price 2023-01-31 11:53 ` Jonathan Cameron 2023-01-31 11:53 ` Jonathan Cameron via
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20221220153453.00000436@Huawei.com \ --to=jonathan.cameron@huawei.com \ --cc=a.manzanares@samsung.com \ --cc=alison.schofield@intel.com \ --cc=bwidawsk@kernel.org \ --cc=cbrowy@avery-design.com \ --cc=dave@stgolabs.net \ --cc=gourry.memverge@gmail.com \ --cc=gregory.price@memverge.com \ --cc=hchkuo@avery-design.com.tw \ --cc=ira.weiny@intel.com \ --cc=linux-cxl@vger.kernel.org \ --cc=qemu-devel@nongnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.