On Wed, Apr 13, 2022 at 10:02:58PM +0800, Yi Liu wrote:
> > +/**
> > + * iopt_unmap_iova() - Remove a range of iova
> > + * @iopt: io_pagetable to act on
> > + * @iova: Starting iova to unmap
> > + * @length: Number of bytes to unmap
> > + *
> > + * The requested range must exactly match an existing range.
> > + * Splitting/truncating IOVA mappings is not allowed.
> > + */
> > +int iopt_unmap_iova(struct io_pagetable *iopt, unsigned long iova,
> > + unsigned long length)
> > +{
> > + struct iopt_pages *pages;
> > + struct iopt_area *area;
> > + unsigned long iova_end;
> > + int rc;
> > +
> > + if (!length)
> > + return -EINVAL;
> > +
> > + if (check_add_overflow(iova, length - 1, &iova_end))
> > + return -EOVERFLOW;
> > +
> > + down_read(&iopt->domains_rwsem);
> > + down_write(&iopt->iova_rwsem);
> > + area = iopt_find_exact_area(iopt, iova, iova_end);
>
> when testing vIOMMU with Qemu using iommufd, I hit a problem as log #3
> shows. Qemu failed when trying to do map due to an IOVA still in use.
> After debugging, the 0xfffff000 IOVA is mapped but not unmapped. But per log
> #2, Qemu has issued unmap with a larger range (0xff000000 -
> 0x100000000) which includes the 0xfffff000. But iopt_find_exact_area()
> doesn't find any area. So 0xfffff000 is not unmapped. Is this correct? Same
> test passed with vfio iommu type1 driver. any idea?
There are a couple of good reasons why the iopt_unmap_iova() should
proccess any contiguous range of fully contained areas, so I would
consider this something worth fixing. can you send a small patch and
test case and I'll fold it in?
Thanks,
Jason
