Re: [RFC PATCH] cxl: Support Global Persistent Flush (GPF)

[Yuquan Wang <wangyuquan1236@phytium.com.cn>]

On Tue, Dec 10, 2024 at 03:47:21PM -0800, Dan Williams wrote:
> Davidlohr Bueso wrote:
> 
> Hi Davidlohr, thanks for this:
> 
> > Add support for GPF flows. It is found that the CXL specification
> > around this to be a bit too involved from the driver side. And while
> > this should really all handled by the hardware, this patch takes
> > things with a grain of salt.
> > 
> > - Dirty shutdown is not handled, and puts the responsibility on the
> > Admin to deal with any GPF failure - otherwise the kernel will just
> > keep using the device upon next boot. Hence no SetShutdownState DIRTY
> > upon memdev probe (and no need for clearing upon successful flush).
> > 
> > - As such, the driver will only update port timeouts throughout the
> > decode hierarchy, upon device probing and hot-remove. These timeouts
> > can be over-specified, particularly T1. Set the max and rely on
> > devices to minimize GPF response times to avoid the worst case wait
> > times that those timeouts imply.
> > 
> > - Energy budgeting is not supported.
> 
> The missing detail for me is why are the defaults likely to be broken
> such that the kernel must get involved in setting them, and how does
> the kernel determine they are broken?
> 
> It is unfortunate that the specification does not recommend default
> values for this, or even an implementation note about what system
> software is supposed to do with these registers.
> 
> Can you say a bit more about the end user visible effects when the
> timeouts are violated? Because the critical enabling from my perspective
> is timeout detection (notifying the sysadmin), not timeout setting. 
> 
> A policy for setting the timeouts makes sense, but I am not sure that
> the kernel should pick "max" as a default policy. Especially when max is
> 80 seconds which is already longer than lockup detectors would tolerate.
> Likely anything over 30 seconds the kernel should be active complaining
> about something being broken. If a configuration needs more time that
> likely needs a user policy override mechanism.
> 
> This would be consistent with what we did for mailbox initialization
> timeouts. Pick a "kernel reasonable" default and provide an override for
> outlier cases.

Hi, list

Except GPF flows, could we use cxl pmem as a special nvdimm device in kernel
including using ADR mechanism? As the cxl_pmem module would bridge the cxl
pmem device from cxl subsystem into the nvdimm subsystem.

Many Thanks
Yuquan