[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <672401a5ab2de_8a670294ae@iweiny-mobl.notmuch>
Date: Thu, 31 Oct 2024 17:16:05 -0500
From: Ira Weiny <ira.weiny@...el.com>
To: Fan Ni <nifan.cxl@...il.com>, Davidlohr Bueso <dave@...olabs.net>
CC: <ira.weiny@...el.com>, Dave Jiang <dave.jiang@...el.com>, Jonathan Cameron
<Jonathan.Cameron@...wei.com>, Navneet Singh <navneet.singh@...el.com>,
Jonathan Corbet <corbet@....net>, Andrew Morton <akpm@...ux-foundation.org>,
Dan Williams <dan.j.williams@...el.com>, Alison Schofield
<alison.schofield@...el.com>, Vishal Verma <vishal.l.verma@...el.com>,
<linux-cxl@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<nvdimm@...ts.linux.dev>, <linux-kernel@...r.kernel.org>, Kees Cook
<kees@...nel.org>, "Gustavo A. R. Silva" <gustavoars@...nel.org>,
<linux-hardening@...r.kernel.org>
Subject: Re: [PATCH v5 08/27] cxl/mem: Read dynamic capacity configuration
from the device
Fan Ni wrote:
> On Wed, Oct 30, 2024 at 06:34:41PM -0700, Davidlohr Bueso wrote:
> > On Tue, 29 Oct 2024, ira.weiny@...el.com wrote:
> >
> > > +/* See CXL 3.1 Table 8-164 get dynamic capacity config Output Payload */
> > > +struct cxl_mbox_get_dc_config_out {
> > > + u8 avail_region_count;
> > > + u8 regions_returned;
> > > + u8 rsvd[6];
> > > + /* See CXL 3.1 Table 8-165 */
> > > + struct cxl_dc_region_config {
> > > + __le64 region_base;
> > > + __le64 region_decode_length;
> > > + __le64 region_length;
> > > + __le64 region_block_size;
> > > + __le32 region_dsmad_handle;
> > > + u8 flags;
> > > + u8 rsvd[3];
> > > + } __packed region[] __counted_by(regions_retunred);
> > > + /* Trailing fields unused */
> > > +} __packed;
> > > +#define CXL_DYNAMIC_CAPACITY_SANITIZE_ON_RELEASE_FLAG BIT(0)
> >
> > Fan, is this something qemu wants to support?
> Currently in Qemu the flag is not used, from emulation perspective, I do
> not see a good reaon to support it for now. Maybe we will need to support it
> later when we consider security?
FWIW I see those fields being more applicable to an FM or orchestrator who is
looking for the devices capabilities. But I'm unsure how those fields are used
in those connections or if they may need to bubble up on a host implementation.
Regardless I think those fields should be added when a real use for them
arises. But I wanted to make the comment here so that future implementers know
they were omitted on purpose.
Ira
Powered by blists - more mailing lists