From: Joao Martins <joao.m.martins@oracle.com>
To: "Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
Avihai Horon <avihaih@nvidia.com>
Cc: "alex@shazbot.org" <alex@shazbot.org>,
"clg@redhat.com" <clg@redhat.com>,
"mst@redhat.com" <mst@redhat.com>,
"jasowang@redhat.com" <jasowang@redhat.com>,
"Liu, Yi L" <yi.l.liu@intel.com>,
"clement.mathieu--drif@eviden.com"
<clement.mathieu--drif@eviden.com>,
"eric.auger@redhat.com" <eric.auger@redhat.com>,
"Hao, Xudong" <xudong.hao@intel.com>,
"Cabiddu, Giovanni" <giovanni.cabiddu@intel.com>,
Rohith S R <rohith.s.r@intel.com>,
"Gross, Mark" <mark.gross@intel.com>,
"Van De Ven, Arjan" <arjan.van.de.ven@intel.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v4 08/10] vfio/migration: Fix a check on vbasedev->iommu_dirty_tracking
Date: Thu, 30 Oct 2025 10:17:12 +0000 [thread overview]
Message-ID: <fbfe567f-c8d0-4342-a593-efe48d7050ad@oracle.com> (raw)
In-Reply-To: <IA3PR11MB913625D418E023D14D4ED0CF92FBA@IA3PR11MB9136.namprd11.prod.outlook.com>
On 30/10/2025 09:10, Duan, Zhenzhong wrote:
>> From: Avihai Horon <avihaih@nvidia.com>
>> On 29/10/2025 11:53, Zhenzhong Duan wrote:
>>
>> BTW, do you have a real production use case for migration with VFIO
>> IOMMU type1 dirty tracking? I mean, is the scenario you described in
>> patch #7 a real use case or you just fixed it for completeness?
>> If there is no use case, maybe patch #9 is not really needed?
>
> patch7 is a real use case, in guest, we switch device from IOMMU domain to block domain and see the issue.
> We need to send accurate unmap notification with actual mapping during migration, for both backend.
>
I think the real question is why you are using type1 backend overall for
purposes of dirty tracking.
type1 dirty tracking just returns everything in the bitmap as 1s. There's no
actual dirty tracking and we usually call 'perpectual' dirty tracking because
everything DMA mapped as write is always returned as dirty no matter what you
do. It doesn't look at pagetable neither for the unmap get dirty.
It's only (known) use has been for testing (in the lack of IOMMU HW + IOMMUFD)
But reading your statement in a different way: you are saying that you use *two*
backends at the same time? Why would you do that?
next prev parent reply other threads:[~2025-10-30 10:19 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-29 9:53 [PATCH v4 00/10] vfio: relax the vIOMMU check Zhenzhong Duan
2025-10-29 9:53 ` [PATCH v4 01/10] vfio/iommufd: Add framework code to support getting dirty bitmap before unmap Zhenzhong Duan
2025-10-29 9:53 ` [PATCH v4 02/10] vfio/iommufd: Query dirty bitmap before DMA unmap Zhenzhong Duan
2025-10-29 9:53 ` [PATCH v4 03/10] vfio/container-legacy: rename vfio_dma_unmap_bitmap() to vfio_legacy_dma_unmap_get_dirty_bitmap() Zhenzhong Duan
2025-10-29 9:53 ` [PATCH v4 04/10] vfio: Introduce a helper vfio_device_dirty_pages_disabled() Zhenzhong Duan
2025-10-29 9:53 ` [PATCH v4 05/10] vfio: Add a backend_flag parameter to vfio_contianer_query_dirty_bitmap() Zhenzhong Duan
2025-10-29 9:53 ` [PATCH v4 06/10] vfio/iommufd: Add IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR flag support Zhenzhong Duan
2025-10-29 9:53 ` [PATCH v4 07/10] intel_iommu: Fix unmap_bitmap failure with legacy VFIO backend Zhenzhong Duan
2025-10-29 9:53 ` [PATCH v4 08/10] vfio/migration: Fix a check on vbasedev->iommu_dirty_tracking Zhenzhong Duan
2025-10-30 8:21 ` Avihai Horon
2025-10-30 9:10 ` Duan, Zhenzhong
2025-10-30 10:17 ` Joao Martins [this message]
2025-10-30 13:06 ` Duan, Zhenzhong
2025-10-30 13:38 ` Joao Martins
2025-10-31 2:40 ` Duan, Zhenzhong
2025-10-29 9:53 ` [PATCH v4 09/10] vfio/migration: Add migration blocker if VM memory is too large to cause unmap_bitmap failure Zhenzhong Duan
2025-10-29 9:53 ` [PATCH v4 10/10] vfio/migration: Allow live migration with vIOMMU without VFs using device dirty tracking Zhenzhong Duan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fbfe567f-c8d0-4342-a593-efe48d7050ad@oracle.com \
--to=joao.m.martins@oracle.com \
--cc=alex@shazbot.org \
--cc=arjan.van.de.ven@intel.com \
--cc=avihaih@nvidia.com \
--cc=clement.mathieu--drif@eviden.com \
--cc=clg@redhat.com \
--cc=eric.auger@redhat.com \
--cc=giovanni.cabiddu@intel.com \
--cc=jasowang@redhat.com \
--cc=mark.gross@intel.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rohith.s.r@intel.com \
--cc=xudong.hao@intel.com \
--cc=yi.l.liu@intel.com \
--cc=zhenzhong.duan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).