All of lore.kernel.org
 help / color / mirror / Atom feed
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







  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 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.