Re: [Qemu-devel] [PATCH v8 3/6] vfio iommu: Add support for mediated devices

[Tian, Kevin]

> From: Alex Williamson [mailto:address@hidden
> Sent: Wednesday, October 12, 2016 6:07 AM
> > @@ -696,6 +1067,11 @@ static int vfio_iommu_replay(struct vfio_iommu *iommu,
> >
> >                     iova += size;
> >             }
> > +
> > +           if (!dma->iommu_mapped) {
> > +                   dma->iommu_mapped = true;
> > +                   vfio_update_accounting(iommu, dma);
> > +           }
> 
> This is the case where we potentially have pinned pfns and we've added
> an iommu mapped device and need to adjust accounting.  But we've fully
> pinned and accounted the entire iommu mapped space while still holding
> the accounting for any pfn mapped space.  So for a time, assuming some
> pfn pinned pages, we have duplicate accounting.  How does userspace
> deal with that?  For instance, if I'm using an mdev device where the
> vendor driver has pinned 512MB of guest memory, then I hot-add an
> assigned NIC and the entire VM address space gets pinned, that pinning
> will fail unless my locked memory limits are at least 512MB in excess
> of my VM size.  Additionally, the user doesn't know how much memory the
> vendor driver is going to pin, it might be the whole VM address space,
> so the user would need 2x the locked memory limits.
> 

Looks we have inconsistent policies in local/remote pining:

- for local pinning, it increases accounting only when the region hasn't
been pinned in remote path

- however in remote pinning, it always increases accounting and then
adjust back if the region has been pinned in local path earlier. This leaves
a window as you said where double accounting may occur on some pages.

What about adding similar check in remote pining, i.e. increasing account
only when the region hasn't been pinned in local path? That way the 
accounting could be always accurate...

Thanks
Kevin