[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v16 Kernel 5/7] vfio iommu: Update UNMAP_DMA ioctl to get dir

From: Kirti Wankhede
Subject: Re: [PATCH v16 Kernel 5/7] vfio iommu: Update UNMAP_DMA ioctl to get dirty bitmap before unmap
Date: Fri, 27 Mar 2020 03:09:44 +0530
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 3/25/2020 7:48 AM, Yan Zhao wrote:
On Wed, Mar 25, 2020 at 03:32:37AM +0800, Kirti Wankhede wrote:
DMA mapped pages, including those pinned by mdev vendor drivers, might
get unpinned and unmapped while migration is active and device is still
running. For example, in pre-copy phase while guest driver could access
those pages, host device or vendor driver can dirty these mapped pages.
Such pages should be marked dirty so as to maintain memory consistency
for a user making use of dirty page tracking.

To get bitmap during unmap, user should allocate memory for bitmap, set
size of allocated memory, set page size to be considered for bitmap and

Signed-off-by: Kirti Wankhede <address@hidden>
Reviewed-by: Neo Jia <address@hidden>
  drivers/vfio/vfio_iommu_type1.c | 54 ++++++++++++++++++++++++++++++++++++++---
  include/uapi/linux/vfio.h       | 10 ++++++++
  2 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 27ed069c5053..b98a8d79e13a 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -982,7 +982,8 @@ static int verify_bitmap_size(uint64_t npages, uint64_t 
static int vfio_dma_do_unmap(struct vfio_iommu *iommu,
-                            struct vfio_iommu_type1_dma_unmap *unmap)
+                            struct vfio_iommu_type1_dma_unmap *unmap,
+                            struct vfio_bitmap *bitmap)
        uint64_t mask;
        struct vfio_dma *dma, *dma_last = NULL;
@@ -1033,6 +1034,10 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu,
         * will be returned if these conditions are not met.  The v2 interface
         * will only return success and a size of zero if there were no
         * mappings within the range.
+        *
+        * When VFIO_DMA_UNMAP_FLAG_GET_DIRTY_BITMAP flag is set, unmap request
+        * must be for single mapping. Multiple mappings with this flag set is
+        * not supported.
        if (iommu->v2) {
                dma = vfio_find_dma(iommu, unmap->iova, 1);
@@ -1040,6 +1045,13 @@ static int vfio_dma_do_unmap(struct vfio_iommu *iommu,
                        ret = -EINVAL;
                        goto unlock;
+               if ((unmap->flags & VFIO_DMA_UNMAP_FLAG_GET_DIRTY_BITMAP) &&
+                   (dma->iova != unmap->iova || dma->size != unmap->size)) {
potential NULL pointer!

And could you address the comments in v14?
How to handle DSI unmaps in vIOMMU

Sorry, I drafted reply to it, but I missed to send, it remained in my drafts

> it happens in vIOMMU Domain level invalidation of IOTLB
> (domain-selective invalidation, see vtd_iotlb_domain_invalidate() in qemu).
> common in VTD lazy mode, and NOT just happening once at boot time.
> rather than invalidate page by page, it batches the page invalidation.
> so, when this invalidation takes place, even higher level page tables
> have been invalid and therefore it has to invalidate a bigger combined range.
> That's why we see IOVAs are mapped in 4k pages, but are unmapped in 2M
> pages.
> I think those UNMAPs should also have GET_DIRTY_BIMTAP flag on, right?

    vtd_sync_shadow_page_table_range(vtd_as, &ce, 0, UINT64_MAX)
        vtd_page_walk_level() - walk over specific level for IOVA range

In the above trace, isn't page walk will take care of creating proper IOTLB entry which should be same as created during mapping for that IOTLB entry?

>>> Such unmap would callback vfio_iommu_map_notify() in QEMU. In
>>> vfio_iommu_map_notify(), unmap is called on same range <iova,
>>> iotlb->addr_mask + 1> which was used for map. Secondly unmap with bitmap
>>> will be called only when device state has _SAVING flag set.
> in this case, iotlb->addr_mask in unmap is 0x200000 -1.
> different than 0x1000 -1 used for map.
>> It might be helpful for Yan, and everyone else, to see the latest QEMU
>> patch series.  Thanks,
> yes, please. also curious of log_sync part for vIOMMU. given most IOVAs in
> address space are unmapped and therefore no IOTLBs are able to be found.
Qemu patches compatible with v16 version are at:

Hope that helps.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]