On 12/6/2022 6:52 PM, Alex Williamson wrote:
> On Tue, 6 Dec 2022 13:55:46 -0800
> Steve Sistare <steven.sistare@xxxxxxxxxx> 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?
Ideally I would like all kernels to support either the old or new vaddr interface.
If iommufd + vfio compat does not make 6.2, then I prefer not to delete the old
interface separately.
> 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,
Sure. I will study iommufd and make a proposal.
Will you review these patches as is to give feedback on the approach?
If I show that iommufd and the vfio compat layer can support these interfaces,
are you open to accepting these in v6.2 if iommufd is still a ways off? I see
iommufd in qemu-next, but not the compat layer.
- Steve
