On Fri, Mar 19, 2021 at 05:21:22PM +0000, Alan Adamson wrote:

quoted

On Mar 19, 2021, at 8:30 AM, Christoph Hellwig [off-list ref] wrote:

On Sat, Mar 20, 2021 at 12:22:08AM +0900, Keith Busch wrote:

quoted

quoted

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.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme