From: "Cédric Le Goater" <clg@redhat.com>
To: "Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
Joao Martins <joao.m.martins@oracle.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "alex.williamson@redhat.com" <alex.williamson@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>,
"avihaih@nvidia.com" <avihaih@nvidia.com>,
"Hao, Xudong" <xudong.hao@intel.com>,
"Cabiddu, Giovanni" <giovanni.cabiddu@intel.com>,
"Gross, Mark" <mark.gross@intel.com>,
"Van De Ven, Arjan" <arjan.van.de.ven@intel.com>
Subject: Re: [PATCH 3/5] vfio/iommufd: Add IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR flag support
Date: Thu, 9 Oct 2025 14:43:00 +0200 [thread overview]
Message-ID: <835d840f-ad65-4f09-8d5c-051e32641ace@redhat.com> (raw)
In-Reply-To: <IA3PR11MB9136EAD2D625ED90DD89A13492EEA@IA3PR11MB9136.namprd11.prod.outlook.com>
Hello Zhenzhong, Joao,
On 10/9/25 12:20, Duan, Zhenzhong wrote:
> Hi Cédric,
>
>> -----Original Message-----
>> From: Cédric Le Goater <clg@redhat.com>
>> Subject: Re: [PATCH 3/5] vfio/iommufd: Add
>> IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR flag support
>>
>> On 9/22/25 07:49, Duan, Zhenzhong wrote:
>>> Hi Joao,
>>>
>>>> -----Original Message-----
>>>> From: Joao Martins <joao.m.martins@oracle.com>
>>>> Subject: Re: [PATCH 3/5] vfio/iommufd: Add
>>>> IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR flag support
>>>>
>>>> On 10/09/2025 03:36, Zhenzhong Duan wrote:
>>>>> Pass IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR when doing the
>> last
>>>> dirty
>>>>> bitmap query right before unmap, no PTEs flushes. This accelerates the
>>>>> query without issue because unmap will tear down the mapping anyway.
>>>>>
>>>>> Add a new element dirty_tracking_flags in VFIOIOMMUFDContainer to
>>>>> be used for the flags of iommufd dirty tracking. Currently it is
>>>>> set to either IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR or 0 based
>> on
>>>>> the scenario.
>>>>>
>>>>> Co-developed-by: Joao Martins <joao.m.martins@oracle.com>
>>>>> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
>>>>> Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
>>>>> Tested-by: Xudong Hao <xudong.hao@intel.com>
>>>>> Tested-by: Giovannio Cabiddu <giovanni.cabiddu@intel.com>
>>>>> ---
>>>>> hw/vfio/vfio-iommufd.h | 1 +
>>>>> include/system/iommufd.h | 2 +-
>>>>> backends/iommufd.c | 5 +++--
>>>>> hw/vfio/iommufd.c | 6 +++++-
>>>>> backends/trace-events | 2 +-
>>>>> 5 files changed, 11 insertions(+), 5 deletions(-)
>>>>>
>>>>> diff --git a/hw/vfio/vfio-iommufd.h b/hw/vfio/vfio-iommufd.h
>>>>> index 07ea0f4304..e0af241c75 100644
>>>>> --- a/hw/vfio/vfio-iommufd.h
>>>>> +++ b/hw/vfio/vfio-iommufd.h
>>>>> @@ -26,6 +26,7 @@ typedef struct VFIOIOMMUFDContainer {
>>>>> VFIOContainerBase bcontainer;
>>>>> IOMMUFDBackend *be;
>>>>> uint32_t ioas_id;
>>>>> + uint64_t dirty_tracking_flags;
>>>>> QLIST_HEAD(, VFIOIOASHwpt) hwpt_list;
>>>>> } VFIOIOMMUFDContainer;
>>>>>
>>>>> diff --git a/include/system/iommufd.h b/include/system/iommufd.h
>>>>> index c9c72ffc45..63898e7b0d 100644
>>>>> --- a/include/system/iommufd.h
>>>>> +++ b/include/system/iommufd.h
>>>>> @@ -64,7 +64,7 @@ bool
>>>> iommufd_backend_set_dirty_tracking(IOMMUFDBackend *be, uint32_t
>>>> hwpt_id,
>>>>> bool iommufd_backend_get_dirty_bitmap(IOMMUFDBackend *be,
>>>> uint32_t hwpt_id,
>>>>> uint64_t iova,
>> ram_addr_t
>>>> size,
>>>>> uint64_t page_size,
>>>> uint64_t *data,
>>>>> - Error **errp);
>>>>> + uint64_t flags, Error
>>>> **errp);
>>>>> bool iommufd_backend_invalidate_cache(IOMMUFDBackend *be,
>>>> uint32_t id,
>>>>> uint32_t data_type,
>>>> uint32_t entry_len,
>>>>> uint32_t *entry_num,
>> void
>>>> *data,
>>>>> diff --git a/backends/iommufd.c b/backends/iommufd.c
>>>>> index 2a33c7ab0b..3c4f6157e2 100644
>>>>> --- a/backends/iommufd.c
>>>>> +++ b/backends/iommufd.c
>>>>> @@ -361,7 +361,7 @@ bool
>>>> iommufd_backend_get_dirty_bitmap(IOMMUFDBackend *be,
>>>>> uint32_t hwpt_id,
>>>>> uint64_t iova,
>> ram_addr_t
>>>> size,
>>>>> uint64_t page_size,
>>>> uint64_t *data,
>>>>> - Error **errp)
>>>>> + uint64_t flags, Error
>> **errp)
>>>>> {
>>>>> int ret;
>>>>> struct iommu_hwpt_get_dirty_bitmap get_dirty_bitmap = {
>>>>> @@ -371,11 +371,12 @@ bool
>>>> iommufd_backend_get_dirty_bitmap(IOMMUFDBackend *be,
>>>>> .length = size,
>>>>> .page_size = page_size,
>>>>> .data = (uintptr_t)data,
>>>>> + .flags = flags,
>>>>> };
>>>>>
>>>>> ret = ioctl(be->fd, IOMMU_HWPT_GET_DIRTY_BITMAP,
>>>> &get_dirty_bitmap);
>>>>> trace_iommufd_backend_get_dirty_bitmap(be->fd, hwpt_id,
>> iova,
>>>> size,
>>>>> - page_size, ret ?
>> errno :
>>>> 0);
>>>>> + flags, page_size,
>> ret ?
>>>> errno : 0);
>>>>> if (ret) {
>>>>> error_setg_errno(errp, errno,
>>>>> "IOMMU_HWPT_GET_DIRTY_BITMAP
>>>> (iova: 0x%"HWADDR_PRIx
>>>>> diff --git a/hw/vfio/iommufd.c b/hw/vfio/iommufd.c
>>>>> index 0057488ce9..c897aa6b17 100644
>>>>> --- a/hw/vfio/iommufd.c
>>>>> +++ b/hw/vfio/iommufd.c
>>>>> @@ -62,7 +62,7 @@ static int iommufd_cdev_unmap_one(const
>>>> VFIOContainerBase *bcontainer,
>>>>> hwaddr iova, ram_addr_t
>> size,
>>>>> IOMMUTLBEntry *iotlb)
>>>>> {
>>>>> - const VFIOIOMMUFDContainer *container =
>>>>> + VFIOIOMMUFDContainer *container =
>>>>> container_of(bcontainer, VFIOIOMMUFDContainer,
>>>> bcontainer);
>>>>> bool need_dirty_sync = false;
>>>>> Error *local_err = NULL;
>>>>> @@ -73,9 +73,12 @@ static int iommufd_cdev_unmap_one(const
>>>> VFIOContainerBase *bcontainer,
>>>>> if (iotlb && vfio_container_dirty_tracking_is_started(bcontainer))
>> {
>>>>> if
>>>> (!vfio_container_devices_dirty_tracking_is_supported(bcontainer) &&
>>>>> bcontainer->dirty_pages_supported) {
>>>>> + container->dirty_tracking_flags =
>>>>> +
>>>> IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR;
>>>>> ret = vfio_container_query_dirty_bitmap(bcontainer,
>> iova,
>>>> size,
>>>>>
>>>> iotlb->translated_addr,
>>>>>
>>>> &local_err);
>>>>> + container->dirty_tracking_flags = 0;
>>>>
>>>> Why not changing vfio_container_query_dirty_bitmap to pass a flags too,
>> like
>>>> the
>>>> original patches? This is a little unnecssary odd style to pass a flag via
>>>> container structure rather and then clearing.
>>>
>>> Just want to be simpler, original patch introduced a new parameter to
>> almost all
>>> variants of *_query_dirty_bitmap() while the flags parameter is only used by
>>> IOMMUFD backend when doing unmap_bitmap. Currently we already have
>> three
>>> backends, legacy VFIO, IOMMUFD and VFIO-user, only IOMMUFD need the
>> flag.
>>>
>>> I take container->dirty_tracking_flags as a notification mechanism, so set it
>> before
>>> vfio_container_query_dirty_bitmap() and clear it thereafter. Maybe clearing
>> it in
>>> iommufd_query_dirty_bitmap() is easier to be acceptable?
>>>
>>>>
>>>> Part of the reason the original series had a VFIO_GET_DIRTY_NO_FLUSH
>> for
>>>> generic
>>>> container abstraction was to not mix IOMMUFD UAPI specifics into base
>>>> container
>>>> API. Then in getting a VFIO_GET_DIRTY_NO_FLUSH, then type1 backend
>>>> could just
>>>> ignore the flag, while IOMMUFD translates it to
>>>> IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR
>>>
>>> I did port original patch
>> https://github.com/yiliu1765/qemu/commit/99f83595d79d2e4170c9e456cf1
>> a7b9521bd4f80
>>> But it looks complex to have 'flags' parameter everywhere.
>> I think I would prefer like Joao to avoid caching information if possible
>> but I haven't check closely the mess it would introduce in the code. Let
>> me check.
>
> Kindly ping. Just in case you have further comments on this.
Regarding the whole series,
* [1/5] vfio/iommufd: Add framework code to support getting dirty bitmap before unmap
Needs refactoring. iommufd_cdev_unmap_one() seems superfluous now ?
* [2/5] vfio/iommufd: Query dirty bitmap before DMA unmap
Looks OK.
In an extra patch, could we rename 'vfio_dma_unmap_bitmap()' to
'vfio_legacy_dma_unmap_get_dirty_bitmap()' ? Helps (me) remember
what it does.
* [3/5] vfio/iommufd: Add IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR flag support
Sorry, I lost track of the discussion between you and Joao regarding
the new '->dirty_tracking_flags' attribute.
I'd prefer adding a 'backend_flag' parameter, even if it’s currently
only used by IOMMUFD. Since we’re not going to redefine all possible
IOMMU backend flags, we can treat it as an opaque parameter for
the upper container layer and document it as such.
Is that ok for you ? A bit more churn for you but Joao did provide
some parts.
* [4/5] intel_iommu: Optimize unmap_bitmap during migration
Ack by Clément may be ?
* [5/5] vfio/migration: Allow live migration with vIOMMU without VFs
using device dirty tracking
ok.
Thanks,
C.
next prev parent reply other threads:[~2025-10-09 12:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 2:36 [PATCH 0/5] vfio: relax the vIOMMU check Zhenzhong Duan
2025-09-10 2:36 ` [PATCH 1/5] vfio/iommufd: Add framework code to support getting dirty bitmap before unmap Zhenzhong Duan
2025-09-19 9:30 ` Cédric Le Goater
2025-09-22 3:17 ` Duan, Zhenzhong
2025-09-22 8:27 ` Cédric Le Goater
2025-09-23 2:45 ` Duan, Zhenzhong
2025-09-23 7:06 ` Cédric Le Goater
2025-09-23 9:50 ` Duan, Zhenzhong
2025-09-10 2:36 ` [PATCH 2/5] vfio/iommufd: Query dirty bitmap before DMA unmap Zhenzhong Duan
2025-09-10 2:36 ` [PATCH 3/5] vfio/iommufd: Add IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR flag support Zhenzhong Duan
2025-09-19 10:27 ` Joao Martins
2025-09-22 5:49 ` Duan, Zhenzhong
2025-09-22 16:02 ` Cédric Le Goater
2025-09-22 16:06 ` Joao Martins
2025-09-22 17:01 ` Joao Martins
2025-09-23 2:50 ` Duan, Zhenzhong
2025-09-23 9:17 ` Joao Martins
2025-09-23 9:55 ` Duan, Zhenzhong
2025-09-23 10:06 ` Duan, Zhenzhong
2025-09-23 2:47 ` Duan, Zhenzhong
2025-10-09 10:20 ` Duan, Zhenzhong
2025-10-09 12:43 ` Cédric Le Goater [this message]
2025-10-10 4:09 ` Duan, Zhenzhong
2025-09-10 2:37 ` [PATCH 4/5] intel_iommu: Optimize unmap_bitmap during migration Zhenzhong Duan
2025-10-12 10:31 ` Yi Liu
2025-10-13 2:50 ` Duan, Zhenzhong
2025-10-13 12:56 ` Yi Liu
2025-10-14 2:31 ` Duan, Zhenzhong
2025-09-10 2:37 ` [PATCH 5/5] 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=835d840f-ad65-4f09-8d5c-051e32641ace@redhat.com \
--to=clg@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=arjan.van.de.ven@intel.com \
--cc=avihaih@nvidia.com \
--cc=clement.mathieu--drif@eviden.com \
--cc=eric.auger@redhat.com \
--cc=giovanni.cabiddu@intel.com \
--cc=jasowang@redhat.com \
--cc=joao.m.martins@oracle.com \
--cc=mark.gross@intel.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--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).