Re: [RFC PATCH v1] cxl: add support for cxl reset

[Ira Weiny <ira.weiny@intel.com>]

Srirangan Madhavan wrote:
>  External email: Use caution opening links or attachments
> 
> Hello Ira!
> 
> Thank you so much for your comments. I’ve added my response below.
> Apologies for the slight delay.
> 
> > Srirangan Madhavan wrote:
> >> Currently, there is a lack of support for the CXL Reset method for cxl
> >> devices. This change adds the support and implements the common reset
> >> steps as laid out by the CXL Spec v3.1 Sections 9.6 & 9.7.
> 
> > I'm not sure what the use case for this support is.  Do you have a use
> > case in mind?
> 
> I think that this change would be broadly useful due to few interrelated
> reasons. Without the change, even if devices are capable of CXL reset,
> users will not be able to access the method. Considering the changes
> to support type 2 devices are being added now, there will be more such
> devices.

I see use cases for type 2 for sure.

>
> Adding the support would enable cases where more fine grained
> reset is required than bus reset methods/conventional reset. And FLR does
> not affect the CXL.cache/CXL.mem protocols. Spec also mentions cases like
> FM uses CXL reset for rebinding, error recovery. So I think that adding this
> change would be useful for all devices with the capability.
> 
> > What happens if there are current cxl regions mapped to the device being
> > reset?  I don't think it is enough to flush the caches.  Section 9.7
> > talks about system software requirements for the HDMs.  How are those
> > requirements met with this patch?
> 
> Sorry for not covering that. Your & other maintainer input here would be
> much appreciated. Since “system software” here is not very specifc,
> my proposal here is not very specific as well.
> 
> Considering different platforms might have specific operations to
> effectively clear the regions, some type of optional helper routines in the
> CXL core would be appropriate.  This way if required, a Type 2 device driver
> for example can choose to use it if required.

There are a couple of ways to go here.  For memory devices I think this is
on the user.  But I don't think that is a primary use case as I'm still
unclear of why a user would need to do any reset of the memory device.

For type 2 devices I think the use case will be device dependant.  The
specific driver in that case will need to tear down their regions (with or
without user space coordination) and then issue the reset.

All that said I think this patch belongs with a series which implements
some device support.  Or is more general for type 2.  Which is what
Alejandro (cc'ed) is working on.

https://lore.kernel.org/linux-cxl/20241216161042.42108-1-alejandro.lucero-palau@amd.com/

Ira