Linux CXL
 help / color / mirror / Atom feed
From: Gregory Price <gregory.price@memverge.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Gregory Price <gourry.memverge@gmail.com>,
	qemu-devel@nongnu.org, linux-cxl@vger.kernel.org,
	Alison Schofield <alison.schofield@intel.com>,
	"a.manzanares@samsung.com" <a.manzanares@samsung.com>,
	Ben Widawsky <bwidawsk@kernel.org>
Subject: Re: [PATCH RFC] hw/cxl: type 3 devices can now present volatile or persistent memory
Date: Fri, 7 Oct 2022 14:46:04 -0400	[thread overview]
Message-ID: <Y0Bz7OrSxBYNGfNR@memverge.com> (raw)
In-Reply-To: <20221007181619.gumcab46ftnvhwbi@offworld>

On Fri, Oct 07, 2022 at 11:16:19AM -0700, Davidlohr Bueso wrote:
> 
> Yeah, putting this back together was on my todo list, but happy to see
> patches are out. Recollecting my thoughts on this, my original approach
> was also to support only volatile or persistent capacities, but through
> two backends, and thus two address spaces. Afaik the last idea that was
> discussed on IRC in this regard was to do it with a single backend along
> with a pmem_offset=N boundary (0 or 100% for example for one type or the
> other) tunnable.
> 

This makes sense.  References another message I sent, are the region
areas in the dvsecs an artifact from cxl1.x? They suggest only two
regions are supported.  Was this overridden by the introduction of CDAT
fields that describe the memory layout?

(sorry, just trying to put together the puzzle pieces here, jumping in a
bit late to the party).

> > > > > >  Example command lines
> > > > > >  ---------------------
> > > > > > -A very simple setup with just one directly attached CXL Type 3 device::
> > > > > > +A very simple setup with just one directly attached CXL Type 3 Persistent Memory device::
> > > > > >
> > > > > >    qemu-system-aarch64 -M virt,gic-version=3,cxl=on -m 4g,maxmem=8G,slots=8 -cpu max \
> > > > > >    ...
> > > > > > @@ -308,7 +308,18 @@ A very simple setup with just one directly attached CXL Type 3 device::
> > > > > >    -object memory-backend-file,id=cxl-lsa1,share=on,mem-path=/tmp/lsa.raw,size=256M \
> > > > > >    -device pxb-cxl,bus_nr=12,bus=pcie.0,id=cxl.1 \
> > > > > >    -device cxl-rp,port=0,bus=cxl.1,id=root_port13,chassis=0,slot=2 \
> > > > > > -  -device cxl-type3,bus=root_port13,memdev=cxl-mem1,lsa=cxl-lsa1,id=cxl-pmem0 \
> > > > > > +  -device cxl-type3,bus=root_port13,pmem=true,memdev=cxl-mem1,lsa=cxl-lsa1,id=cxl-pmem0 \
> 
> So regardless of the interface we end up with, volatile and lsa parameters
> should be mutually exclusive.
> 

Spec says that volatile devices `may` implement an lsa.

Get LSA (Opcode 4102h)
The Label Storage Area (LSA) shall be supported by a memory device
that provides persistent memory capacity and may be supported by a
device that provides only volatile memory capacity. The format of
the LSA is specified in Section 9.13.2. The size of the Label Storage
Area is retrieved from the Identify Memory Device command.

  reply	other threads:[~2022-10-07 18:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20221006000103.49542-1-gregory.price@memverge.com>
2022-10-06  8:45 ` [PATCH RFC] hw/cxl: type 3 devices can now present volatile or persistent memory Jonathan Cameron
2022-10-06  8:50   ` Jonathan Cameron
2022-10-06 15:52     ` Gregory Price
2022-10-06 16:42       ` Jonathan Cameron
2022-10-06 17:29         ` Gregory Price
2022-10-10 14:43           ` Jonathan Cameron
2022-10-10 15:20             ` Gregory Price
2022-10-10 16:26               ` Jonathan Cameron
2022-10-10 16:32             ` Jonathan Cameron
2022-10-10 17:18             ` Davidlohr Bueso
     [not found]           ` <CAD3UvdT1ZHJDaqj05C+n7t4rM7yhjZyM6fooXAfG12rAYnBqmw@mail.gmail.com>
2022-10-10 15:18             ` Jonathan Cameron
2022-10-10 15:25               ` Gregory Price
2022-10-11  1:23                 ` Gregory Price
2022-10-11 17:14                   ` Davidlohr Bueso
2022-10-11 17:22                     ` Gregory Price
2022-10-11 17:28                       ` Jonathan Cameron
2022-10-07 18:16         ` Davidlohr Bueso
2022-10-07 18:46           ` Gregory Price [this message]
2022-10-07 19:55             ` Davidlohr Bueso
2022-10-07 19:52     ` Davidlohr Bueso

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=Y0Bz7OrSxBYNGfNR@memverge.com \
    --to=gregory.price@memverge.com \
    --cc=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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox