On 12/7/2022 10:19 AM, Jason Gunthorpe wrote:
> 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@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?
>
> 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.
Alex, your opinion? Implement in iommufd only, or also in type1? The latter
makes it more feasible to port to stable kernels and allow qemu with live update
to run on them. I imagine porting iommufd to a stable kernel would be heavy lift,
and be considered too risky.
- Steve
