On Thu, May 07, 2020 at 08:56:33PM -0300, Jason Gunthorpe wrote:
On Thu, May 07, 2020 at 06:22:23PM -0400, Peter Xu wrote:But shouldn't open() only be called when the VMA is created for a memory range?
On Thu, May 07, 2020 at 04:03:34PM -0600, Alex Williamson wrote:If the VMA has a mapping then that specific VMA has to be in the
On Thu, 7 May 2020 17:47:44 -0400Yes, I don't see much problem either on doing the vma_list maintainance only in
Peter Xu <peterx@xxxxxxxxxx> wrote:
Hi, Alex,It's not required. I originally did this so that I'm not allocating a
On Tue, May 05, 2020 at 03:54:53PM -0600, Alex Williamson wrote:
+/*A pure question: is this only a safety-belt or it is required in some known
+ * Zap mmaps on open so that we can fault them in on access and therefore
+ * our vma_list only tracks mappings accessed since last zap.
+ */
+static void vfio_pci_mmap_open(struct vm_area_struct *vma)
+{
+ zap_vma_ptes(vma, vma->vm_start, vma->vm_end - vma->vm_start);
scenarios?
vma_list entry in a path where I can't return error, but as Jason
suggested I could zap here only in the case that I do encounter that
allocation fault. However I still like consolidating the vma_list
handling to the vm_ops .fault and .close callbacks and potentially we
reduce the zap latency by keeping the vma_list to actual users, which
we'll get to eventually anyway in the VM case as memory BARs are sized
and assigned addresses.
.fault() and .close(). My understandingg is that the worst case is the perf
critical applications (e.g. DPDK) could pre-fault these MMIO region easily
during setup if they want. My question was majorly about whether the vma
should be guaranteed to have no mapping at all when .open() is called. But I
agree with you that it's always good to have that as safety-belt anyways.
linked list.
So if the zap is skipped then the you have to allocate something and
add to the linked list to track the VMA with mapping.
It is not a 'safety belt'
If so, does it also mean that the address range must have not been mapped yet?
Thanks,