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: Mon, 22 Sep 2025 18:02:17 +0200 [thread overview]
Message-ID: <ac9e71a9-972d-4fba-a0f1-9823ae6664cb@redhat.com> (raw)
In-Reply-To: <IA3PR11MB9136B9DA08CC2A48E1678DED9212A@IA3PR11MB9136.namprd11.prod.outlook.com>
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/99f83595d79d2e4170c9e456cf1a7b9521bd4f80
> 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.
Thanks,
C.
next prev parent reply other threads:[~2025-09-22 16:03 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 [this message]
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
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=ac9e71a9-972d-4fba-a0f1-9823ae6664cb@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).