On Thu, 8 Dec 2022 14:09:44 -0500
Steven Sistare <steven.sistare@xxxxxxxxxx> wrote:
> 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.
I understand your concerns, but this isn't really an upstream stable
kernel discussion. The only thing relevant to an upstream stable
kernel is the removal of the old, vulnerable interface, which I'm
preparing to queue for v6.2. The new re-implementation isn't eligible
for upstream stable backports, imo.
So I suspect the only stable kernel relevant to the new implementation
is a downstream stable kernel. While I agree that backporting iommufd
to get this feature is a heavy lift, the alternative is asking upstream
QEMU and kernel to accept and maintain a separate interface in a
backend slated for deprecation. That's a lot.
I expect you'll be in good company pushing for downstream support of
iommufd given the various improvements and features it offers. No
offense, but QEMU live update might not even be the primary reason that
a downstream ought to be interested in iommufd. Thanks,
Alex
