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

[Alan Adamson]

> 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.

I guess the question is: should we get  show-regs to work without having to map in
the registers?

Alan


> 
> Fabrics should always work, though, because we retrieve CSTS through an
> admin command rather than memory mapped IO.