All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joao Martins <joao.m.martins@oracle.com>
To: "Duan, Zhenzhong" <zhenzhong.duan@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: "Liu, Yi L" <yi.l.liu@intel.com>,
	Eric Auger <eric.auger@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Cedric Le Goater <clg@redhat.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Avihai Horon <avihaih@nvidia.com>
Subject: Re: [PATCH v5 09/13] vfio/iommufd: Probe and request hwpt dirty tracking capability
Date: Mon, 22 Jul 2024 15:13:26 +0100	[thread overview]
Message-ID: <952e96f2-24e6-4595-92fc-a8abec746c12@oracle.com> (raw)
In-Reply-To: <0ba48105-c129-4221-bfe3-f2c714bc12b2@oracle.com>

On 22/07/2024 15:09, Joao Martins wrote:
> On 22/07/2024 09:58, Joao Martins wrote:
>> On 22/07/2024 07:05, Duan, Zhenzhong wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Joao Martins <joao.m.martins@oracle.com>
>>>> Subject: [PATCH v5 09/13] vfio/iommufd: Probe and request hwpt dirty
>>>> tracking capability
>>>>
>>>> In preparation to using the dirty tracking UAPI, probe whether the IOMMU
>>>> supports dirty tracking. This is done via the data stored in
>>>> hiod::caps::hw_caps initialized from GET_HW_INFO.
>>>>
>>>> Qemu doesn't know if VF dirty tracking is supported when allocating
>>>> hardware pagetable in iommufd_cdev_autodomains_get(). This is because
>>>> VFIODevice migration state hasn't been initialized *yet* hence it can't pick
>>>> between VF dirty tracking vs IOMMU dirty tracking. So, if IOMMU supports
>>>> dirty tracking it always creates HWPTs with
>>>> IOMMU_HWPT_ALLOC_DIRTY_TRACKING
>>>> even if later on VFIOMigration decides to use VF dirty tracking instead.
>>>
>>> I thought there is no overhead for HWPT with IOMMU_HWPT_ALLOC_DIRTY_TRACKING vs. HWPT without IOMMU_HWPT_ALLOC_DIRTY_TRACKING if we don't enable dirty tracking. Right?
>>>
>>
>> Correct.
>>
>>>>
>>>> Signed-off-by: Joao Martins <joao.m.martins@oracle.com>
>>>> ---
>>>> include/hw/vfio/vfio-common.h |  1 +
>>>> hw/vfio/iommufd.c             | 19 +++++++++++++++++++
>>>> 2 files changed, 20 insertions(+)
>>>>
>>>> diff --git a/include/hw/vfio/vfio-common.h b/include/hw/vfio/vfio-
>>>> common.h
>>>> index 4e44b26d3c45..7e530c7869dc 100644
>>>> --- a/include/hw/vfio/vfio-common.h
>>>> +++ b/include/hw/vfio/vfio-common.h
>>>> @@ -97,6 +97,7 @@ typedef struct IOMMUFDBackend IOMMUFDBackend;
>>>>
>>>> typedef struct VFIOIOASHwpt {
>>>>     uint32_t hwpt_id;
>>>> +    uint32_t hwpt_flags;
>>>>     QLIST_HEAD(, VFIODevice) device_list;
>>>>     QLIST_ENTRY(VFIOIOASHwpt) next;
>>>> } VFIOIOASHwpt;
>>>> diff --git a/hw/vfio/iommufd.c b/hw/vfio/iommufd.c
>>>> index bb44d948c735..2e5c207bbca0 100644
>>>> --- a/hw/vfio/iommufd.c
>>>> +++ b/hw/vfio/iommufd.c
>>>> @@ -110,6 +110,11 @@ static void
>>>> iommufd_cdev_unbind_and_disconnect(VFIODevice *vbasedev)
>>>>     iommufd_backend_disconnect(vbasedev->iommufd);
>>>> }
>>>>
>>>> +static bool iommufd_hwpt_dirty_tracking(VFIOIOASHwpt *hwpt)
>>>> +{
>>>> +    return hwpt && hwpt->hwpt_flags &
>>>> IOMMU_HWPT_ALLOC_DIRTY_TRACKING;
>>>> +}
>>>> +
>>>> static int iommufd_cdev_getfd(const char *sysfs_path, Error **errp)
>>>> {
>>>>     ERRP_GUARD();
>>>> @@ -246,6 +251,17 @@ static bool
>>>> iommufd_cdev_autodomains_get(VFIODevice *vbasedev,
>>>>         }
>>>>     }
>>>>
>>>> +    /*
>>>> +     * This is quite early and VFIO Migration state isn't yet fully
>>>> +     * initialized, thus rely only on IOMMU hardware capabilities as to
>>>> +     * whether IOMMU dirty tracking is going to be requested. Later
>>>> +     * vfio_migration_realize() may decide to use VF dirty tracking
>>>> +     * instead.
>>>> +     */
>>>> +    if (vbasedev->hiod->caps.hw_caps &
>>>> IOMMU_HW_CAP_DIRTY_TRACKING) {
>>>
>>> Looks there is still reference to hw_caps, then would suggest to bring back the NEW CAP.
>>>
>> Ah, but below helper is checking for GET_HW_INFO stuff, and not hwpt flags
>> given that we haven't allocated a hwpt yet.
>>
>> While I could place this check into a helper it would only have an user. I will
>> need below helper iommufd_hwpt_dirty_tracking() in another patch, so this is a
>> bit of a one off check only (unless we want a new helper for cosmetic purposes)
>>
>>>> +        flags = IOMMU_HWPT_ALLOC_DIRTY_TRACKING;
>>>> +    }
>>>> +
>>>>     if (!iommufd_backend_alloc_hwpt(iommufd, vbasedev->devid,
>>>>                                     container->ioas_id, flags,
>>>>                                     IOMMU_HWPT_DATA_NONE, 0, NULL,
>>>> @@ -255,6 +271,7 @@ static bool
>>>> iommufd_cdev_autodomains_get(VFIODevice *vbasedev,
>>>>
>>>>     hwpt = g_malloc0(sizeof(*hwpt));
>>>>     hwpt->hwpt_id = hwpt_id;
>>>> +    hwpt->hwpt_flags = flags;
>>>>     QLIST_INIT(&hwpt->device_list);
>>>>
>>>>     ret = iommufd_cdev_attach_ioas_hwpt(vbasedev, hwpt->hwpt_id, errp);
>>>> @@ -267,6 +284,8 @@ static bool
>>>> iommufd_cdev_autodomains_get(VFIODevice *vbasedev,
>>>>     vbasedev->hwpt = hwpt;
>>>>     QLIST_INSERT_HEAD(&hwpt->device_list, vbasedev, hwpt_next);
>>>>     QLIST_INSERT_HEAD(&container->hwpt_list, hwpt, next);
>>>> +    container->bcontainer.dirty_pages_supported |=
>>>> +                              iommufd_hwpt_dirty_tracking(hwpt);
>>>
>>> If there is at least one hwpt without dirty tracking, shouldn't we make bcontainer.dirty_pages_supported false?
>>>
> 
> Missed this comment. We could set to false but the generic container abstraction
> is utilizing this to let the ioctls() of the individual backend to go through to
> the defined callback, and that's why I set to true.
> 
Let me rephrase, I meant:  "(...) utilizing this to let the individual backend
container callbacks of dirty tracking to go through, and that's why I set to true."

> And that is really the only effect of this patch. By the time we reach to patch
> 12 (which is what really enables live migration with IOMMU automatically), the
> IOMMUFD dirty tracking is only called 1) when not one of the VF doesn't support
> device dirty tracking [only if you're using IOMMUFD backend], and finally 2)
> that no VF/mdev has added the migration blocker which essentially looks at the
> HWPT flags (as opposed to the container attribute).
> 
> 	Joao
> 



  reply	other threads:[~2024-07-22 14:14 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-19 12:04 [PATCH v5 00/13] hw/iommufd: IOMMUFD Dirty Tracking Joao Martins
2024-07-19 12:04 ` [PATCH v5 01/13] vfio/pci: Extract mdev check into an helper Joao Martins
2024-07-19 14:09   ` Cédric Le Goater
2024-07-22  5:13   ` Duan, Zhenzhong
2024-07-23  7:00   ` Eric Auger
2024-07-19 12:04 ` [PATCH v5 02/13] vfio/iommufd: Don't initialize nor set a HOST_IOMMU_DEVICE with mdev Joao Martins
2024-07-19 12:04 ` [PATCH v5 03/13] backends/iommufd: Extend iommufd_backend_get_device_info() to fetch HW capabilities Joao Martins
2024-07-19 12:04 ` [PATCH v5 04/13] vfio/iommufd: Return errno in iommufd_cdev_attach_ioas_hwpt() Joao Martins
2024-07-19 12:04 ` [PATCH v5 05/13] vfio/iommufd: Introduce auto domain creation Joao Martins
2024-07-22  5:16   ` Duan, Zhenzhong
2024-07-22  8:50     ` Joao Martins
2024-07-22 14:21       ` Cédric Le Goater
2024-07-23  2:36         ` Duan, Zhenzhong
2024-07-23  4:36       ` Duan, Zhenzhong
2024-07-19 12:04 ` [PATCH v5 06/13] vfio/{iommufd,container}: Remove caps::aw_bits Joao Martins
2024-07-22  5:22   ` Duan, Zhenzhong
2024-07-22  8:53     ` Joao Martins
2024-07-23  5:30       ` Duan, Zhenzhong
2024-07-19 12:04 ` [PATCH v5 07/13] vfio/iommufd: Add hw_caps field to HostIOMMUDeviceCaps Joao Martins
2024-07-22 14:06   ` Cédric Le Goater
2024-07-19 12:04 ` [PATCH v5 08/13] vfio/{iommufd, container}: Invoke HostIOMMUDevice::realize() during attach_device() Joao Martins via
2024-07-19 14:10   ` [PATCH v5 08/13] vfio/{iommufd,container}: " Cédric Le Goater
2024-07-22  5:32   ` Duan, Zhenzhong
2024-07-19 12:04 ` [PATCH v5 09/13] vfio/iommufd: Probe and request hwpt dirty tracking capability Joao Martins
2024-07-22  6:05   ` Duan, Zhenzhong
2024-07-22  8:58     ` Joao Martins
2024-07-22 14:09       ` Joao Martins
2024-07-22 14:13         ` Joao Martins [this message]
2024-07-23  3:07           ` Duan, Zhenzhong
2024-07-19 12:04 ` [PATCH v5 10/13] vfio/iommufd: Implement VFIOIOMMUClass::set_dirty_tracking support Joao Martins
2024-07-22  6:15   ` Duan, Zhenzhong
2024-07-19 12:04 ` [PATCH v5 11/13] vfio/iommufd: Implement VFIOIOMMUClass::query_dirty_bitmap support Joao Martins
2024-07-22  6:16   ` Duan, Zhenzhong
2024-07-19 12:05 ` [PATCH v5 12/13] vfio/migration: Don't block migration device dirty tracking is unsupported Joao Martins
2024-07-19 14:17   ` Cédric Le Goater
2024-07-19 14:24     ` Joao Martins
2024-07-19 15:32       ` Joao Martins
2024-07-19 17:26       ` Joao Martins
2024-07-22 14:53         ` Cédric Le Goater
2024-07-22 15:01           ` Joao Martins
2024-07-22 15:13             ` Cédric Le Goater
2024-07-22 15:42               ` Joao Martins
2024-07-22 15:58                 ` Cédric Le Goater
2024-07-22 16:29                   ` Joao Martins
2024-07-22 17:04                     ` Cédric Le Goater
2024-07-22 17:15                       ` Cédric Le Goater
2024-07-22 18:08                         ` Joao Martins
2024-07-22 18:01                       ` Joao Martins
2024-07-23  6:38                         ` Cédric Le Goater
2024-07-19 12:05 ` [PATCH v5 13/13] vfio/common: Allow disabling device dirty page tracking Joao Martins
2024-07-19 12:13 ` [PATCH v5 00/13] hw/iommufd: IOMMUFD Dirty Tracking Joao Martins
2024-07-19 22:19 ` [PATCH v5.1 12/13] vfio/migration: Don't block migration device dirty tracking is unsupported Joao Martins
2024-07-22 13:51 ` [PATCH v5 00/13] hw/iommufd: IOMMUFD Dirty Tracking Cédric Le Goater

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=952e96f2-24e6-4595-92fc-a8abec746c12@oracle.com \
    --to=joao.m.martins@oracle.com \
    --cc=alex.williamson@redhat.com \
    --cc=avihaih@nvidia.com \
    --cc=clg@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=qemu-devel@nongnu.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.