On Wed, Oct 19, 2016 at 12:48:14PM -0600, Stephen Bates wrote: > On Tue, Oct 18, 2016 at 08:51:15PM -0700, Dan Williams wrote: > > [ adding Ashok and David for potential iommu comments ] > > > > Hi Dan > > Thanks for adding Ashok and David! > > > > > I agree with the motivation and the need for a solution, but I have > > some questions about this implementation. > > > > > > > > Consumers > > > --------- > > > > > > We provide a PCIe device driver in an accompanying patch that can be > > > used to map any PCIe BAR into a DAX capable block device. For > > > non-persistent BARs this simply serves as an alternative to using > > > system memory bounce buffers. For persistent BARs this can serve as an > > > additional storage device in the system. > > > > Why block devices? I wonder if iopmem was initially designed back > > when we were considering enabling DAX for raw block devices. However, > > that support has since been ripped out / abandoned. You currently > > need a filesystem on top of a block-device to get DAX operation. > > Putting xfs or ext4 on top of PCI-E memory mapped range seems awkward > > if all you want is a way to map the bar for another PCI-E device in > > the topology. > > > > If you're only using the block-device as a entry-point to create > > dax-mappings then a device-dax (drivers/dax/) character-device might > > be a better fit. > > > > We chose a block device because we felt it was intuitive for users to > carve up a memory region but putting a DAX filesystem on it and creating > files on that DAX aware FS. It seemed like a convenient way to > partition up the region and to be easily able to get the DMA address > for the memory backing the device. You do realise that local filesystems can silently change the location of file data at any point in time, so there is no such thing as a "stable mapping" of file data to block device addresses in userspace? If you want remote access to the blocks owned and controlled by a filesystem, then you need to use a filesystem with a remote locking mechanism to allow co-ordinated, coherent access to the data in those blocks. Anything else is just asking for ongoing, unfixable filesystem corruption or data leakage problems (i.e. security issues). Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
