On Wed, Apr 01, 2020 at 07:20:59PM -0700, Dan Williams wrote: > On Wed, Apr 1, 2020 at 12:19 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > On Mon, Mar 30, 2020 at 02:27:06PM -0700, Dave Jiang wrote: > > > Since there is no standard way that defines a PCI device that receives > > > descriptors or commands with synchronous write operations, add quirk to set > > > cmdmem for the Intel accelerator device that supports it. > > > > Why do we need a quirk for this? Even assuming a flag is needed in > > struct pci_dev (and I don't really understand why that is needed to > > start with), it could be set in ->probe. > > The consideration in my mind is whether this new memory type and > instruction combination warrants a new __attribute__((noderef, > address_space(X))) separate from __iomem. If it stays a single device > concept layered on __iomem then yes, I agree it can all live locally > in the driver. However, when / if this facility becomes wider spread, > as the PCI ECR in question is trending, it might warrant general > annotation. > > The enqcmds instruction does not operate on typical x86 mmio > addresses, only these special device portals offer the ability to have > non-posted writes with immediate results in the cpu condition code > flags. But that is not what this series does at all. And I think it makes sense to wait until it gains adoption to think about a different address space. In this series we could just trivially kill patches 2-4 and make it much easier to understand.
