On Thu, 2010-07-29 at 15:57 -0700, Jason Gunthorpe wrote: > > You would need to modify ib_umem_get() to check for the VM_PFNMAP > > flag and build the struct ib_umem similar to the proposed > > ib_iomem_get(). However, the page reference counting/sharing issue > > would need to be solved. I think there are kernel level callbacks > > for this that could be used. > > But in this case the pages are already mmaped into a user process, > there must be some mechanism to ensure they don't get pulled away?!
Yes. The VM_PFNMAP flag means the device is the owner of the memory and has to handle unmmap. Since the rest of the kernel won't allow that memory to be shared, swapped out, etc., only the driver has to be notified or handle when it goes away. > Though, I guess, what happens if you hot un-plug the PCI-E card that > has a process mmaping its memory?! The hot un-plug would have to close the device first which would unmmap the memory or the device would not allow the hot un-plug to happed by saying it is busy. > What happens if you RDMA READ from PCI-E address space that does not > have any device responding? Well, RDMA reads with a Mellanox style HCA may cause problems because I don't know if they support PCIe to PCIe DMAs. If the device isn't responding to PCIe reads of its memory, the root complex will timeout the read transaction and signal the initiator (CPU) which will cause a bus error signal. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
