From: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
To: Ben Widawsky <ben@bwidawsk.net>
Cc: "Thomas Huth" <thuth@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Vishal Verma" <vishal.l.verma@intel.com>,
"Chris Browy" <cbrowy@avery-design.com>,
qemu-devel@nongnu.org, "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Prashant V Agarwal" <agpr123@gmail.com>,
"Igor Mammedov" <imammedo@redhat.com>,
"Dan Williams" <dan.j.williams@intel.com>
Subject: Re: [RFC PATCH v2 24/32] hw/cxl/device: Add a memory device (8.2.8.5)
Date: Thu, 28 Jan 2021 17:40:09 +0000 [thread overview]
Message-ID: <20210128174009.00007536@Huawei.com> (raw)
In-Reply-To: <20210128165801.pvskbbkogz722sns@mail.bwidawsk.net>
On Thu, 28 Jan 2021 08:58:01 -0800
Ben Widawsky <ben@bwidawsk.net> wrote:
> On 21-01-28 08:51:51, Ben Widawsky wrote:
> > On 21-01-28 07:14:44, Ben Widawsky wrote:
> > > On 21-01-28 07:03:18, Ben Widawsky wrote:
> > > > On 21-01-28 10:25:38, Jonathan Cameron wrote:
> > > > > On Wed, 27 Jan 2021 13:26:45 -0800
> > > > > Ben Widawsky <ben.widawsky@intel.com> wrote:
> > > > >
> > > > > > On 21-01-27 22:03:12, Igor Mammedov wrote:
> > > > > > > On Tue, 5 Jan 2021 08:53:15 -0800
> > > > > > > Ben Widawsky <ben.widawsky@intel.com> wrote:
> > > > > > >
> > > > > > > > A CXL memory device (AKA Type 3) is a CXL component that contains some
> > > > > > > > combination of volatile and persistent memory. It also implements the
> > > > > > > > previously defined mailbox interface as well as the memory device
> > > > > > > > firmware interface.
> > > > > > > >
> > > > > > > > The following example will create a 256M device in a 512M window:
> > > > > > > >
> > > > > > > > -object "memory-backend-file,id=cxl-mem1,share,mem-path=cxl-type3,size=512M"
> > > > > > > > -device "cxl-type3,bus=rp0,memdev=cxl-mem1,id=cxl-pmem0,size=256M"
> > > > > > >
> > > > > > > I'd expect whole backend used by frontend, so one would not need "size" property
> > > > > > > on frontend (like we do with memory devices).
> > > > > > > So question is why it partially uses memdev?
> > > > > >
> > > > > > Answered in a separate thread...
> > > > >
> > > > > One possible suggestion inline.
> > > > >
> > > > > > > > +
> > > > > > > > +static void cxl_setup_memory(CXLType3Dev *ct3d, Error **errp)
> > > > > > > > +{
> > > > > > > > + MemoryRegionSection mrs;
> > > > > > > > + MemoryRegion *mr;
> > > > > > > > + uint64_t offset = 0;
> > > > > > > > + size_t remaining_size;
> > > > > > > > +
> > > > > > > > + if (!ct3d->hostmem) {
> > > > > > > > + error_setg(errp, "memdev property must be set");
> > > > > > > > + return;
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + /* FIXME: need to check mr is the host bridge's MR */
> > > > > > > > + mr = host_memory_backend_get_memory(ct3d->hostmem);
> > > > > > > > +
> > > > > > > > + /* Create our new subregion */
> > > > > > > > + ct3d->cxl_dstate.pmem = g_new(MemoryRegion, 1);
> > > > > > > > +
> > > > > > > > + /* Find the first free space in the window */
> > > > > > > > + WITH_RCU_READ_LOCK_GUARD()
> > > > > > > > + {
> > > > > > > > + mrs = memory_region_find(mr, offset, 1);
> > > > > > > > + while (mrs.mr && mrs.mr != mr) {
> > > > > > > > + offset += memory_region_size(mrs.mr);
> > > > > > > > + mrs = memory_region_find(mr, offset, 1);
> > > > > > > > + }
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + remaining_size = memory_region_size(mr) - offset;
> > > > > > > > + if (remaining_size < ct3d->size) {
> > > > > > > > + g_free(ct3d->cxl_dstate.pmem);
> > > > > > > > + error_setg(errp,
> > > > > > > > + "Not enough free space (%zd) required for device (%" PRId64 ")",
> > > > > > > > + remaining_size, ct3d->size);
> > > > > > > > + }
> > > > > > > > +
> > > > > > > > + /* Register our subregion as non-volatile */
> > > > > > > > + memory_region_init_ram(ct3d->cxl_dstate.pmem, OBJECT(ct3d),
> > > > > > > > + "cxl_type3-memory", ct3d->size, errp);
> > > > > > > this allocates ct3d->size of anon RAM, was this an intention?
> > > > > > > If yes, can you clarify why extra RAM is used instead of using what
> > > > > > > backend provides?
> > > > > >
> > > > > > It sounds like I'm doing the wrong thing then. There should be one chunk of
> > > > > > memory which is a subset of the full memory backend object. Could you please
> > > > > > advise on what I should be doing instead? Is add_subregion() sufficient?
> > > > >
> > > > > Taking inspiration from nvdimm I'm carrying a patch that uses
> > > > > memory_region_init_alias(ct3d->cxl_dstate.pmem, OBJECT(qct3d)q,
> > > > > "cxl_type3-memory", mr, offset, ct3d->size);
> > > > >
> > > > > I 'think' that's doing the right thing, but haven't fully tested it yet
> > > > > so may be completely wrong :)
> > > > >
> > > > > Then for the pmem addr, call memory_region_set_address() to put it
> > > > > in a particular location.
> > > > >
> > > >
> > > > Yes - this is what I'd like to do and what I initially tried, and I also believe
> > > > it's right, but it doesn't work.
> > > >
> > > > range_invariant: Assertion `range->lob <= range->upb || range->lob == range->upb + 1' failed.
> > > >
> > > > I was digging into this yesterday, but opted to start a new thread on the
> > > > matter.
> > > >
> > >
> > > Hmm. I think I need to figure out the right add_subregion after this and it
> > > might work. I'll keep digging, but if you have ideas, let me know.
> >
> > [snip]
> >
> > I managed to get a bit further. With the following, I start getting complaints
> > about fragmented memory when adding devices later.
> >
> > memory_region_init_alias(ct3d->cxl_dstate.pmem, OBJECT(ct3d),
> > "cxl_type3-memory", mr, mr->addr + offset, ct3d->size);
> > memory_region_set_nonvolatile(ct3d->cxl_dstate.pmem, true);
> > memory_region_add_subregion(mr, offset, ct3d->cxl_dstate.pmem);
> >
> > -device nvdimm,memdev=nvmem1,id=nv1,label-size=2M,node=5: could not find position in guest address space for memory device - memory fragmented due to alignments
> >
>
> Ignore this. It was a problem with my commandline.
>
> I think I have something limping along now.
Great. It's going to get more interesting to do this 'right' though.
We'll need to define a memory window similar to device_mem which is used for
normal memory hotplug then export that window via the relevant ACPI tables
(once defined somewhere public). Finally we'll then want to actually
do the memory_region_add_subregion() only on the OS / firmware having
configured the type3 device by setting it's PA base.
Going to be fiddly - but should be doable. With it basically working
should be a series of sensible (ish) steps to get there.
Jonathan
next prev parent reply other threads:[~2021-01-28 17:53 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-05 16:52 [RFC PATCH v2 00/32] CXL 2.0 Support Ben Widawsky
2021-01-05 16:52 ` [RFC PATCH v2 01/32] Temp: Add the PCI_EXT_ID_DVSEC definition to the qemu pci_regs.h copy Ben Widawsky
2021-01-05 16:52 ` [RFC PATCH v2 02/32] hw/pci/cxl: Add a CXL component type (interface) Ben Widawsky
2021-01-05 16:52 ` [RFC PATCH v2 03/32] hw/cxl/component: Introduce CXL components (8.1.x, 8.2.5) Ben Widawsky
2021-01-05 16:52 ` [RFC PATCH v2 04/32] hw/cxl/device: Introduce a CXL device (8.2.8) Ben Widawsky
2021-01-05 16:52 ` [RFC PATCH v2 05/32] hw/cxl/device: Implement the CAP array (8.2.8.1-2) Ben Widawsky
2021-01-06 13:28 ` Jonathan Cameron
2021-01-06 16:49 ` Ben Widawsky
2021-01-06 17:06 ` Jonathan Cameron
2021-01-06 17:09 ` Ben Widawsky
2021-01-05 16:52 ` [RFC PATCH v2 06/32] hw/cxl/device: Add device status (8.2.8.3) Ben Widawsky
2021-01-05 16:52 ` [RFC PATCH v2 07/32] hw/cxl/device: Implement basic mailbox (8.2.8.4) Ben Widawsky
2021-01-06 13:21 ` Jonathan Cameron
2021-01-06 16:31 ` Ben Widawsky
2021-01-06 17:40 ` [Linuxarm] " Jonathan Cameron
2021-01-06 18:05 ` Ben Widawsky
2021-01-06 19:08 ` Ben Widawsky
2021-01-08 5:36 ` Ben Widawsky
2021-01-05 16:52 ` [RFC PATCH v2 08/32] hw/cxl/device: Add memory devices (8.2.8.5) Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 09/32] hw/cxl/device: Add cheap EVENTS implementation (8.2.9.1) Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 10/32] hw/cxl/device: Placeholder for firmware commands Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 11/32] hw/cxl/device: Timestamp implementation (8.2.9.3) Ben Widawsky
2021-01-05 17:12 ` Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 12/32] hw/cxl/device: Add log commands (8.2.9.4) + CEL Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 13/32] hw/pxb: Use a type for realizing expanders Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 14/32] hw/pci/cxl: Create a CXL bus type Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 15/32] hw/pxb: Allow creation of a CXL PXB (host bridge) Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 16/32] qtest: allow DSDT acpi table changes Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 17/32] acpi/pci: Consolidate host bridge setup Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 18/32] tests/acpi: remove stale allowed tables Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 19/32] hw/pci: Plumb _UID through host bridges Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 20/32] hw/cxl/component: Implement host bridge MMIO (8.2.5, table 142) Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 21/32] acpi/pxb/cxl: Reserve host bridge MMIO Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 22/32] hw/pxb/cxl: Add "windows" for host bridges Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 23/32] hw/cxl/rp: Add a root port Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 24/32] hw/cxl/device: Add a memory device (8.2.8.5) Ben Widawsky
2021-01-27 21:03 ` Igor Mammedov
2021-01-27 21:11 ` Ben Widawsky
2021-01-27 21:21 ` Igor Mammedov
2021-01-27 21:30 ` Ben Widawsky
2021-01-27 21:26 ` Ben Widawsky
2021-01-28 10:25 ` Jonathan Cameron
2021-01-28 15:03 ` Ben Widawsky
2021-01-28 15:14 ` Ben Widawsky
2021-01-28 16:51 ` Ben Widawsky
2021-01-28 16:58 ` Ben Widawsky
2021-01-28 17:40 ` Jonathan Cameron [this message]
2021-01-05 16:53 ` [RFC PATCH v2 25/32] hw/cxl/device: Implement MMIO HDM decoding (8.2.5.12) Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 26/32] acpi/cxl: Add _OSC implementation (9.14.2) Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 27/32] tests/acpi: allow CEDT table addition Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 28/32] acpi/cxl: Create the CEDT (9.14.1) Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 29/32] Temp: acpi/cxl: Add ACPI0017 (CEDT awareness) Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 30/32] tests/acpi: Add new CEDT files Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 31/32] WIP: i386/cxl: Initialize a host bridge Ben Widawsky
2021-01-05 16:53 ` [RFC PATCH v2 32/32] qtest/cxl: Add very basic sanity tests Ben Widawsky
2021-01-08 18:44 ` [RFC PATCH v2 00/32] CXL 2.0 Support Jonathan Cameron
2021-01-08 18:51 ` Ben Widawsky
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=20210128174009.00007536@Huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=agpr123@gmail.com \
--cc=ben@bwidawsk.net \
--cc=cbrowy@avery-design.com \
--cc=dan.j.williams@intel.com \
--cc=f4bug@amsat.org \
--cc=imammedo@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=vishal.l.verma@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).