On Mon, Feb 5, 2018 at 1:44 PM, Alex Williamson <[email protected]> wrote: > On Sun, 04 Feb 2018 15:05:30 -0800 > Dan Williams <[email protected]> wrote: > >> Filesystem-DAX is incompatible with 'longterm' page pinning. Without >> page cache indirection a DAX mapping maps filesystem blocks directly. >> This means that the filesystem must not modify a file's block map while >> any page in a mapping is pinned. In order to prevent the situation of >> userspace holding of filesystem operations indefinitely, disallow >> 'longterm' Filesystem-DAX mappings. >> >> RDMA has the same conflict and the plan there is to add a 'with lease' >> mechanism to allow the kernel to notify userspace that the mapping is >> being torn down for block-map maintenance. Perhaps something similar can >> be put in place for vfio. >> >> Note that xfs and ext4 still report: >> >> "DAX enabled. Warning: EXPERIMENTAL, use at your own risk" >> >> ...at mount time, and resolving the dax-dma-vs-truncate problem is one >> of the last hurdles to remove that designation. >> >> Cc: Alex Williamson <[email protected]> >> Cc: Michal Hocko <[email protected]> >> Cc: Christoph Hellwig <[email protected]> >> Cc: [email protected] >> Cc: <[email protected]> >> Reported-by: Haozhong Zhang <[email protected]> >> Fixes: d475c6346a38 ("dax,ext2: replace XIP read and write with DAX I/O") >> Signed-off-by: Dan Williams <[email protected]> >> --- >> drivers/vfio/vfio_iommu_type1.c | 18 +++++++++++++++--- >> 1 file changed, 15 insertions(+), 3 deletions(-) > > This isn't without some expense, a vfio mapping and un-mapping unit > test incurs ~1.5% increase in system time losing access to gup_fast(). > Also, I think tce_iommu_use_page() is going to have the same problem, it > provides the same sort of functionality for a different vfio IOMMU > backend. Please take this through your tree and I'll add a todo list > item to see how we might improve this. > > Acked-by: Alex Williamson <[email protected]>
Thanks Alex.
