Re: Is there any plan to support CXL GPF in Linux

[Dan Williams <dan.j.williams@intel.com>]

Christoph Hellwig wrote:
> On Mon, Jul 08, 2024 at 05:42:39PM -0700, Dan Williams wrote:
> > One thing that guide does not cover is what should OS software do with a
> > dirty shutdown failure. To my knowledge there is no specific plumbing
> > for handling NVME device write-cache failures beyond: "hope filesystem
> > logging and metadata checksums can recover a consistent filesystem".
> > 
> > I do agree that the driver has a responsibility to set switch timeout
> > values, but that is more an unfortunate complexity imposed by the spec.
> > Just set the max and rely on devices to minimize GPF response times to
> > avoid the worst case wait times that those timeouts imply. In any event,
> > enabling that is "up for grabs."
> 
> Why would anyone specifically care about a (presumably non-volatile) write
> cache failure?  A non-volatile write cache is simply part of the device
> and it's failure rate guarantee.  So any data lost from it will be
> recovered the same way as a media failure, SOC failure, interconnect
> failure, etc.

Right, my concern is that the CXL specification is over-specified here
in its suggestion that system-software manage the dirty-state each boot.
I assume that if an NVME device experienced a super-cap failure that
prevented its write-cache from being drained on power-loss that event
would be logged somewhere. If administrator did not react to that event,
the kernel would just keep using the device on the next boot as if
nothing happened.

So I am more trying to preclude complicated patches around
dirty-shutdown handling since Yee mentioned the recommendations in the
CXL driver writer's guide. I.e. do not follow that guide explicitly, and
the recommendation to tightly scope GPF timeouts also seem over
specified.