[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v6 10/12] hw/mem/cxl_type3: Add dpa range validation for acce
From: |
Jonathan Cameron |
Subject: |
Re: [PATCH v6 10/12] hw/mem/cxl_type3: Add dpa range validation for accesses to DC regions |
Date: |
Tue, 16 Apr 2024 16:00:56 +0100 |
On Mon, 15 Apr 2024 10:37:00 -0700
fan <nifan.cxl@gmail.com> wrote:
> On Fri, Apr 12, 2024 at 06:54:42PM -0400, Gregory Price wrote:
> > On Mon, Mar 25, 2024 at 12:02:28PM -0700, nifan.cxl@gmail.com wrote:
> > > From: Fan Ni <fan.ni@samsung.com>
> > >
> > > All dpa ranges in the DC regions are invalid to access until an extent
> > > covering the range has been added. Add a bitmap for each region to
> > > record whether a DC block in the region has been backed by DC extent.
> > > For the bitmap, a bit in the bitmap represents a DC block. When a DC
> > > extent is added, all the bits of the blocks in the extent will be set,
> > > which will be cleared when the extent is released.
> > >
> > > Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> > > Signed-off-by: Fan Ni <fan.ni@samsung.com>
> > > ---
> > > hw/cxl/cxl-mailbox-utils.c | 6 +++
> > > hw/mem/cxl_type3.c | 76 +++++++++++++++++++++++++++++++++++++
> > > include/hw/cxl/cxl_device.h | 7 ++++
> > > 3 files changed, 89 insertions(+)
> > >
> > > diff --git a/hw/cxl/cxl-mailbox-utils.c b/hw/cxl/cxl-mailbox-utils.c
> > > index 7094e007b9..a0d2239176 100644
> > > --- a/hw/cxl/cxl-mailbox-utils.c
> > > +++ b/hw/cxl/cxl-mailbox-utils.c
> > > @@ -1620,6 +1620,7 @@ static CXLRetCode cmd_dcd_add_dyn_cap_rsp(const
> > > struct cxl_cmd *cmd,
> > >
> > > cxl_insert_extent_to_extent_list(extent_list, dpa, len, NULL, 0);
> > > ct3d->dc.total_extent_count += 1;
> > > + ct3_set_region_block_backed(ct3d, dpa, len);
> > >
> > > ent = QTAILQ_FIRST(&ct3d->dc.extents_pending);
> > > cxl_remove_extent_from_extent_list(&ct3d->dc.extents_pending,
> > > ent);
> >
> > while looking at the MHD code, we had decided to "reserve" the blocks in
> > the bitmap in the call to `qmp_cxl_process_dynamic_capacity` in order to
> > prevent a potential double-allocation (basically we need to sanity check
> > that two hosts aren't reserving the region PRIOR to the host being
> > notified).
> >
> > I did not see any checks in the `qmp_cxl_process_dynamic_capacity` path
> > to prevent pending extents from being double-allocated. Is this an
> > explicit choice?
> >
> > I can see, for example, why you may want to allow the following in the
> > pending list: [Add X, Remove X, Add X]. I just want to know if this is
> > intentional or not. If not, you may consider adding a pending check
> > during the sanity check phase of `qmp_cxl_process_dynamic_capacity`
> >
> > ~Gregory
>
> First, for remove request, pending list is not involved. See cxl r3.1,
> 9.13.3.3. Pending basically means "pending to add".
> So for the above example, in the pending list, you can see [Add x, add x] if
> the
> event is not processed in time.
> Second, from the spec, I cannot find any text saying we cannot issue
> another add extent X if it is still pending.
I think there is text saying that the capacity is not released for reuse
by the device until it receives a response from the host. Whilst
it's not explicit on offers to the same host, I'm not sure that matters.
So I don't think it is suppose to queue multiple extents...
> From the kernel side, if the first one is accepted, the second one will
> get rejected, and there is no issue there.
> If the first is reject for some reason, the second one can get
> accepted or rejected and do not need to worry about the first one.
>
>
> Fan
>