qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Joao Martins <joao.m.martins@oracle.com>
To: qemu-devel@nongnu.org
Cc: Yi Liu <yi.l.liu@intel.com>, Eric Auger <eric.auger@redhat.com>,
	Zhenzhong Duan <zhenzhong.duan@intel.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Cedric Le Goater <clg@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"Daniel P . Berrange" <berrange@redhat.com>,
	Eduardo Habkost <eduardo@habkost.net>,
	Eric Blake <eblake@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	Avihai Horon <avihaih@nvidia.com>,
	Joao Martins <joao.m.martins@oracle.com>
Subject: [PATCH RFCv2 0/8] vfio/iommufd: IOMMUFD Dirty Tracking
Date: Mon, 12 Feb 2024 13:56:35 +0000	[thread overview]
Message-ID: <20240212135643.5858-1-joao.m.martins@oracle.com> (raw)

This small series adds support for Dirty Tracking in IOMMUFD backend.
The sole reason I still made it RFC is because of the second patch,
where we are implementing user-managed auto domains.

In essence it is quite similar to the original IOMMUFD series where we
would allocate a HWPT, until we switched later on into a IOAS attach.
Patch 2 goes into more detail, but the gist is that there's two modes of
using IOMMUFD and by keep using kernel managed auto domains we would end
up duplicating the same flags we have in HWPT but into the VFIO IOAS
attach. While it is true that just adding a flag is simpler, it also
creates duplication and motivates duplicate what hwpt-alloc already has.
But there's a chance I have the wrong expectation here, so any feedback
welcome.

The series is divided into:

* Patch 1: Adds a simple helper to get device capabilities;

* Patches 2 - 5: IOMMUFD backend support for dirty tracking;

The workflow is relatively simple:

1) Probe device and allow dirty tracking in the HWPT
2) Toggling dirty tracking on/off
3) Read-and-clear of Dirty IOVAs

The heuristics selected for (1) were to enable it *if* device supports
migration but doesn't support VF dirty tracking or IOMMU dirty tracking
is supported. The latter is for the hotplug case where we can add a device
without a tracker and thus still support migration.

The unmap case is deferred until further vIOMMU support with migration
is added[3] which will then introduce the usage of
IOMMU_HWPT_GET_DIRTY_BITMAP_NO_CLEAR in GET_DIRTY_BITMAP ioctl in the
dma unmap bitmap flow.

* Patches 6-8: Add disabling of hugepages to allow tracking at base
page; avoid blocking live migration where there's no VF dirty
tracker, considering that we have IOMMU dirty tracking. And allow
disabling VF dirty tracker via qemu command line.

This series builds on top of Zhengzhong series[0], but only requires the
first 9 patches i.e. up to ("vfio/pci: Initialize host iommu device
instance after attachment")[1] that are more generic IOMMUFD device
plumbing, and doesn't require the nesting counterpart.

This is stored on github:
https://github.com/jpemartins/qemu/commits/iommufd-v5

Note: While Linux v6.7 has IOMMU dirty tracking feature, I suggest folks
use the latest for-rc of iommufd kernel tree as there's some fixes there.

Comments and feedback appreciated.

Cheers,
        Joao

Chances since RFCv1[2]:
* Remove intel/amd dirty tracking emulation enabling
* Remove the dirtyrate improvement for VF/IOMMU dirty tracking
[Will pursue these two in separate series]
* Introduce auto domains support
* Enforce dirty tracking following the IOMMUFD UAPI for this
* Add support for toggling hugepages in IOMMUFD
* Auto enable support when VF supports migration to use IOMMU
when it doesn't have VF dirty tracking
* Add a parameter to toggle VF dirty tracking

[0] https://lore.kernel.org/qemu-devel/20240201072818.327930-1-zhenzhong.duan@intel.com/
[1] https://lore.kernel.org/qemu-devel/20240201072818.327930-10-zhenzhong.duan@intel.com/
[2] https://lore.kernel.org/qemu-devel/20220428211351.3897-1-joao.m.martins@oracle.com/
[3] https://lore.kernel.org/qemu-devel/20230622214845.3980-1-joao.m.martins@oracle.com/

Joao Martins (8):
  backends/iommufd: Introduce helper function
    iommufd_device_get_hw_capabilities()
  vfio/iommufd: Introduce auto domain creation
  vfio/iommufd: Probe and request hwpt dirty tracking capability
  vfio/iommufd: Implement VFIOIOMMUClass::set_dirty_tracking support
  vfio/iommufd: Implement VFIOIOMMUClass::query_dirty_bitmap support
  backends/iommufd: Add ability to disable hugepages
  vfio/migration: Don't block migration device dirty tracking is
    unsupported
  vfio/common: Allow disabling device dirty page tracking

 backends/iommufd.c            | 133 ++++++++++++++++++++++++++++
 backends/trace-events         |   4 +
 hw/vfio/common.c              |  32 ++++++-
 hw/vfio/iommufd.c             | 162 ++++++++++++++++++++++++++++++++++
 hw/vfio/migration.c           |   5 +-
 hw/vfio/pci.c                 |   3 +
 include/hw/vfio/vfio-common.h |  12 +++
 include/sysemu/iommufd.h      |  17 ++++
 qapi/qom.json                 |   2 +-
 9 files changed, 367 insertions(+), 3 deletions(-)

-- 
2.39.3



             reply	other threads:[~2024-02-12 13:58 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12 13:56 Joao Martins [this message]
2024-02-12 13:56 ` [PATCH RFCv2 1/8] backends/iommufd: Introduce helper function iommufd_device_get_hw_capabilities() Joao Martins
2024-02-26  7:29   ` Duan, Zhenzhong
2024-02-26 10:10     ` Joao Martins
2024-02-27  4:04       ` Duan, Zhenzhong
2024-02-12 13:56 ` [PATCH RFCv2 2/8] vfio/iommufd: Introduce auto domain creation Joao Martins
2024-02-12 16:27   ` Jason Gunthorpe
2024-02-12 18:09     ` Joao Martins
2024-02-26  9:14       ` Duan, Zhenzhong
2024-02-13 12:01   ` Joao Martins
2024-02-19  8:58   ` Avihai Horon
2024-02-20 10:42     ` Joao Martins
2024-02-12 13:56 ` [PATCH RFCv2 3/8] vfio/iommufd: Probe and request hwpt dirty tracking capability Joao Martins
2024-02-19  9:03   ` Avihai Horon
2024-02-20 10:51     ` Joao Martins
2024-02-20 12:46       ` Avihai Horon
2024-02-12 13:56 ` [PATCH RFCv2 4/8] vfio/iommufd: Implement VFIOIOMMUClass::set_dirty_tracking support Joao Martins
2024-02-19  9:17   ` Avihai Horon
2024-02-12 13:56 ` [PATCH RFCv2 5/8] vfio/iommufd: Implement VFIOIOMMUClass::query_dirty_bitmap support Joao Martins
2024-02-19  9:30   ` Avihai Horon
2024-02-20 10:59     ` Joao Martins
2024-02-20 12:52       ` Avihai Horon
2024-02-20 13:17         ` Joao Martins
2024-02-12 13:56 ` [PATCH RFCv2 6/8] backends/iommufd: Add ability to disable hugepages Joao Martins
2024-02-12 16:59   ` Jason Gunthorpe
2024-02-12 17:17   ` Markus Armbruster
2024-02-12 19:16     ` Joao Martins
2024-02-19 10:05   ` Avihai Horon
2024-02-20 11:01     ` Joao Martins
2024-02-12 13:56 ` [PATCH RFCv2 7/8] vfio/migration: Don't block migration device dirty tracking is unsupported Joao Martins
2024-02-19 10:12   ` Avihai Horon
2024-02-20 11:05     ` Joao Martins
2024-02-12 13:56 ` [PATCH RFCv2 8/8] vfio/common: Allow disabling device dirty page tracking Joao Martins
2024-02-13 11:59 ` [PATCH RFCv2 0/8] vfio/iommufd: IOMMUFD Dirty Tracking Joao Martins
2024-02-14 15:40   ` Cédric Le Goater
2024-02-14 16:25     ` Joao Martins
2024-02-15 14:20       ` Eric Auger

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=20240212135643.5858-1-joao.m.martins@oracle.com \
    --to=joao.m.martins@oracle.com \
    --cc=alex.williamson@redhat.com \
    --cc=armbru@redhat.com \
    --cc=avihaih@nvidia.com \
    --cc=berrange@redhat.com \
    --cc=clg@redhat.com \
    --cc=eblake@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=eric.auger@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=pbonzini@redhat.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 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).