[PATCH 0/1] nvme: Export CSTS register via sysfs

[Alan Adamson]

Resending this due to some formatting issues.

Need to revisit this issue again.  In the original case we needed to get access to the csts register. We were able to move to using the ’state’ sysfs attribute.

We are now getting a similar request from our manufacturing team. They are using nvme-cli show-regs to assist debug. The ’state’ attribute is not sufficient and they want to use the production version of the kernel (which enables CONFIG_IO_STRICT_DEVMEM) rather than a special kernel. Ideally, we would want nvme-cli show-regs to work whether or not CONFIG_IO_STRICT_DEVMEM is configured. Other than exporting the registers thru sysfs attributes, is there any other mechanism to get show-regs the data it needs?

Alan 

> On Mar 19, 2021, at 10:30 AM, Keith Busch <kbusch at kernel.org> wrote:
> 
> On Fri, Mar 19, 2021 at 05:21:22PM +0000, Alan Adamson wrote:
>> 
>> 
>>> On Mar 19, 2021, at 8:30 AM, Christoph Hellwig <hch at lst.de> wrote:
>>> 
>>> On Sat, Mar 20, 2021 at 12:22:08AM +0900, Keith Busch wrote:
>>>>> I think this is a horrible idea.  Userspace has no business touching
>>>>> registers even read-only.  MMIO reads can have side effects as well,
>>>>> intentional or unintentional, and we also open up a whole can of worms
>>>>> of mismatched memory attributes.
>>>> 
>>>> I was thinking the driver wouldn't opt-in if there were read side
>>>> effects, but yeah, it's too fragile. I withdraw the suggestion.
>>> 
>>> I'd still like to understand what values in CSTS Alan cares about.  I
>>> don't think just dumping a register with somewhat awkward encodings
>>> is a good idea.
>> 
>> Primarily Ready and Failed. I’m reaching out to the requesting team to see if the ’state’ attribute is sufficient.
>> 
>> Back to nvme-cli show-regs, do we just expect this to always fail now our should we be returning good
>> values?
> 
> For PCIe, that shell command returns good values only if the kernel
> wasn't compiled with CONFIG_IO_STRICT_DEVMEM. If the kernel was compiled
> with that option (most are), user space will not be able to access the
> values.
> 
> Fabrics should always work, though, because we retrieve CSTS through an
> admin command rather than memory mapped IO.