Re: [PATCH V1 1/8] vfio: delete interfaces to update vaddr

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Dec 06, 2022 at 04:52:32PM -0700, Alex Williamson wrote:
> On Tue,  6 Dec 2022 13:55:46 -0800
> Steve Sistare <steven.sistare@oracle.com> wrote:
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index d7d8e09..5c5cc7e 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> ...
> > @@ -1265,18 +1256,12 @@ struct vfio_bitmap {
> >   *
> >   * If flags & VFIO_DMA_UNMAP_FLAG_ALL, unmap all addresses.  iova and size
> >   * must be 0.  This cannot be combined with the get-dirty-bitmap flag.
> > - *
> > - * If flags & VFIO_DMA_UNMAP_FLAG_VADDR, do not unmap, but invalidate host
> > - * virtual addresses in the iova range.  Tasks that attempt to translate an
> > - * iova's vaddr will block.  DMA to already-mapped pages continues.  This
> > - * cannot be combined with the get-dirty-bitmap flag.
> >   */
> >  struct vfio_iommu_type1_dma_unmap {
> >  	__u32	argsz;
> >  	__u32	flags;
> >  #define VFIO_DMA_UNMAP_FLAG_GET_DIRTY_BITMAP (1 << 0)
> >  #define VFIO_DMA_UNMAP_FLAG_ALL		     (1 << 1)
> > -#define VFIO_DMA_UNMAP_FLAG_VADDR	     (1 << 2)
> 
> 
> This flag should probably be marked reserved.
> 
> Should we consider this separately for v6.2?

I think we should merge this immediately, given the security problem.

> For the remainder, the long term plan is to move to iommufd, so any new
> feature of type1 would need equivalent support in iommufd.  Thanks,

At a bare minimum nothing should be merged to type1 that doesn't come
along with an iommufd implementation too.

IMHO at this point we should not be changing type1 any more - just do
it iommufd only please. No reason to write and review everything
twice.

Jason