From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Gregory Price <gourry.memverge@gmail.com>
Cc: <qemu-devel@nongnu.org>, <linux-cxl@vger.kernel.org>,
<alison.schofield@intel.com>, <dave@stgolabs.net>,
<a.manzanares@samsung.com>, <bwidawsk@kernel.org>,
Gregory Price <gregory.price@memverge.com>
Subject: Re: [PATCH 2/2] hw/cxl: Allow CXL type-3 devices to be persistent or volatile
Date: Mon, 10 Oct 2022 16:25:15 +0100 [thread overview]
Message-ID: <20221010162515.000009f8@huawei.com> (raw)
In-Reply-To: <20221006233702.18532-2-gregory.price@memverge.com>
On Thu, 6 Oct 2022 19:37:02 -0400
Gregory Price <gourry.memverge@gmail.com> wrote:
> This commit enables setting one memory region for a type-3 device, but
> that region may now be either a persistent region or volatile region.
>
> Future work may enable setting both regions simultaneously, as this is
> a possible configuration on a real type-3 device. The scaffolding was
> put in for this, but is left for further work.
>
> The existing [memdev] property has been deprecated and will default the
> memory region to a persistent memory region (although a user may assign
> the region to a ram or file backed region).
>
> There is presently no interface with which to expose a MemoryRegion's
> real backing type (HostMemoryBackendRam/File), otherwise we could have
> used File to imply pmem (or inspected HostMemoryBackendFile->is_pmem) to
> deterine whether the backing device supported pmem mode. This should be
> considered for future work, as it would make creating an array of
> HostMemory devices to represent DIMMs on a Single-Logical-Device
> MemoryExpander fairly straightforward.
>
> Signed-off-by: Gregory Price <gregory.price@memverge.com>
> ---
Looks good to me, though I haven't tested it yet.
A few trivial comments inline.
> *len = sizeof(*part_info);
> diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
> index 1837c1c83a..998461dac1 100644
> --- a/hw/mem/cxl_type3.c
> +++ b/hw/mem/cxl_type3.c
> @@ -100,18 +100,47 @@ static bool cxl_setup_memory(CXLType3Dev *ct3d, Error **errp)
> DeviceState *ds = DEVICE(ct3d);
> MemoryRegion *mr;
> char *name;
> + bool is_pmem = false;
>
> - if (!ct3d->hostmem) {
> - error_setg(errp, "memdev property must be set");
> + /*
> + * FIXME: For now we only allow a single host memory region.
TODO maybe? FIXME tends to lead to reviewers asking why we haven't
fixed it yet!
> + * Handle the deprecated memdev property usage cases
> + */
> + if (!ct3d->hostmem && !ct3d->host_vmem && !ct3d->host_pmem) {
> + error_setg(errp, "at least one memdev property must be set");
> return false;
> + } else if (ct3d->hostmem && (ct3d->host_vmem || ct3d->host_pmem)) {
> + error_setg(errp, "deprecated [memdev] cannot be used with new "
> + "persistent and volatile memdev properties");
> + return false;
> + } else if (ct3d->hostmem) {
> + warn_report("memdev is deprecated and defaults to pmem. "
> + "Use (persistent|volatile)-memdev instead.");
I'd suggest we don't warn on this yet. There is limited advantage in
doing so given it's easy to carry on supporting by just treating
it as another name for persistent-memdev
> + is_pmem = true;
> + } else {
> + if (ct3d->host_vmem && ct3d->host_pmem) {
> + error_setg(errp, "Multiple memory devices not supported yet");
> + return false;
> + }
> + is_pmem = !!ct3d->host_pmem;
> + ct3d->hostmem = ct3d->host_pmem ? ct3d->host_pmem : ct3d->host_vmem;
> }
>
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Cameron via <qemu-devel@nongnu.org>
To: Gregory Price <gourry.memverge@gmail.com>
Cc: <qemu-devel@nongnu.org>, <linux-cxl@vger.kernel.org>,
<alison.schofield@intel.com>, <dave@stgolabs.net>,
<a.manzanares@samsung.com>, <bwidawsk@kernel.org>,
Gregory Price <gregory.price@memverge.com>
Subject: Re: [PATCH 2/2] hw/cxl: Allow CXL type-3 devices to be persistent or volatile
Date: Mon, 10 Oct 2022 16:25:15 +0100 [thread overview]
Message-ID: <20221010162515.000009f8@huawei.com> (raw)
In-Reply-To: <20221006233702.18532-2-gregory.price@memverge.com>
On Thu, 6 Oct 2022 19:37:02 -0400
Gregory Price <gourry.memverge@gmail.com> wrote:
> This commit enables setting one memory region for a type-3 device, but
> that region may now be either a persistent region or volatile region.
>
> Future work may enable setting both regions simultaneously, as this is
> a possible configuration on a real type-3 device. The scaffolding was
> put in for this, but is left for further work.
>
> The existing [memdev] property has been deprecated and will default the
> memory region to a persistent memory region (although a user may assign
> the region to a ram or file backed region).
>
> There is presently no interface with which to expose a MemoryRegion's
> real backing type (HostMemoryBackendRam/File), otherwise we could have
> used File to imply pmem (or inspected HostMemoryBackendFile->is_pmem) to
> deterine whether the backing device supported pmem mode. This should be
> considered for future work, as it would make creating an array of
> HostMemory devices to represent DIMMs on a Single-Logical-Device
> MemoryExpander fairly straightforward.
>
> Signed-off-by: Gregory Price <gregory.price@memverge.com>
> ---
Looks good to me, though I haven't tested it yet.
A few trivial comments inline.
> *len = sizeof(*part_info);
> diff --git a/hw/mem/cxl_type3.c b/hw/mem/cxl_type3.c
> index 1837c1c83a..998461dac1 100644
> --- a/hw/mem/cxl_type3.c
> +++ b/hw/mem/cxl_type3.c
> @@ -100,18 +100,47 @@ static bool cxl_setup_memory(CXLType3Dev *ct3d, Error **errp)
> DeviceState *ds = DEVICE(ct3d);
> MemoryRegion *mr;
> char *name;
> + bool is_pmem = false;
>
> - if (!ct3d->hostmem) {
> - error_setg(errp, "memdev property must be set");
> + /*
> + * FIXME: For now we only allow a single host memory region.
TODO maybe? FIXME tends to lead to reviewers asking why we haven't
fixed it yet!
> + * Handle the deprecated memdev property usage cases
> + */
> + if (!ct3d->hostmem && !ct3d->host_vmem && !ct3d->host_pmem) {
> + error_setg(errp, "at least one memdev property must be set");
> return false;
> + } else if (ct3d->hostmem && (ct3d->host_vmem || ct3d->host_pmem)) {
> + error_setg(errp, "deprecated [memdev] cannot be used with new "
> + "persistent and volatile memdev properties");
> + return false;
> + } else if (ct3d->hostmem) {
> + warn_report("memdev is deprecated and defaults to pmem. "
> + "Use (persistent|volatile)-memdev instead.");
I'd suggest we don't warn on this yet. There is limited advantage in
doing so given it's easy to carry on supporting by just treating
it as another name for persistent-memdev
> + is_pmem = true;
> + } else {
> + if (ct3d->host_vmem && ct3d->host_pmem) {
> + error_setg(errp, "Multiple memory devices not supported yet");
> + return false;
> + }
> + is_pmem = !!ct3d->host_pmem;
> + ct3d->hostmem = ct3d->host_pmem ? ct3d->host_pmem : ct3d->host_vmem;
> }
>
next prev parent reply other threads:[~2022-10-10 15:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-06 23:37 [PATCH 1/2] hw/cxl: set cxl-type3 device type to PCI_CLASS_MEMORY_CXL Gregory Price
2022-10-06 23:37 ` [PATCH 2/2] hw/cxl: Allow CXL type-3 devices to be persistent or volatile Gregory Price
2022-10-10 15:25 ` Jonathan Cameron [this message]
2022-10-10 15:25 ` Jonathan Cameron via
2022-10-10 17:12 ` Davidlohr Bueso
2022-10-10 19:36 ` Davidlohr Bueso
2022-10-10 20:07 ` Gregory Price
2022-10-07 16:35 ` [PATCH 1/2] hw/cxl: set cxl-type3 device type to PCI_CLASS_MEMORY_CXL Jonathan Cameron
2022-10-07 16:35 ` Jonathan Cameron via
2022-10-07 17:10 ` Davidlohr Bueso
2022-10-07 17:16 ` Davidlohr Bueso
2022-10-26 20:06 ` Michael S. Tsirkin
2022-10-26 20:09 ` Gregory Price
2022-10-26 20:11 ` Michael S. Tsirkin
2022-10-26 21:07 ` Gregory Price
2022-11-03 18:12 ` Jonathan Cameron
2022-11-03 18:12 ` 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=20221010162515.000009f8@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=a.manzanares@samsung.com \
--cc=alison.schofield@intel.com \
--cc=bwidawsk@kernel.org \
--cc=dave@stgolabs.net \
--cc=gourry.memverge@gmail.com \
--cc=gregory.price@memverge.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: link
Be 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.