From: Joao Martins <joao.m.martins@oracle.com> To: qemu-devel@nongnu.org Cc: "Joao Martins" <joao.m.martins@oracle.com>, "Paolo Bonzini" <pbonzini@redhat.com>, "Dr. David Alan Gilbert" <dgilbert@redhat.com>, "Richard Henderson" <richard.henderson@linaro.org>, "Eduardo Habkost" <eduardo@habkost.net>, "Michael S. Tsirkin" <mst@redhat.com>, "Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>, "Peter Xu" <peterx@redhat.com>, "Jason Wang" <jasowang@redhat.com>, "Alex Williamson" <alex.williamson@redhat.com>, "David Hildenbrand" <david@redhat.com>, "Philippe Mathieu-Daudé" <f4bug@amsat.org>, "Cornelia Huck" <cohuck@redhat.com>, "Juan Quintela" <quintela@redhat.com>, "Eric Blake" <eblake@redhat.com>, "Markus Armbruster" <armbru@redhat.com>, "Jason Gunthorpe" <jgg@nvidia.com>, "Nicolin Chen" <nicolinc@nvidia.com>, "Yishai Hadas" <yishaih@nvidia.com>, "Kevin Tian" <kevin.tian@intel.com>, "Yi Liu" <yi.l.liu@intel.com>, "Eric Auger" <eric.auger@redhat.com>, "Thanos Makatos" <thanos.makatos@nutanix.com>, "John G . Johnson" <john.g.johnson@oracle.com>, kvm@vger.kernel.org Subject: [PATCH RFC 00/10] hw/vfio, x86/iommu: IOMMUFD Dirty Tracking Date: Thu, 28 Apr 2022 22:13:41 +0100 [thread overview] Message-ID: <20220428211351.3897-1-joao.m.martins@oracle.com> (raw) This series expands IOMMUFD series from Yi and Eric into supporting IOMMU Dirty Tracking. It adds both the emulated x86 IOMMUs, as well as IOMMUFD support that exercises said emulation (or H/W). It is organized into: * Patches 1 - 4: x86 IOMMU emulation that performs dirty tracking, useful for a nested guest exercising the IOMMUFD kernel counterpart for coverage and development. The caching of the PASID PTE root flags and AMD DTE is not exactly the cleanest, still wondering about a better way without having to lookup context/DTE prior to IOTLB lookup. * Patches 5 - 9: IOMMUFD backend support for dirty tracking; Sadly this wasn't exactly tested with VF Live Migration, but it adds (last 2 patches) a way to measure dirty rate via HMP and QMP. The IOMMUFD kernel patches go into extent on what each of the ioctls do, albeit the workflow is relatively simple: 1) Toggling dirty tracking via HWPT_SET_DIRTY or get -ENOTSUPP otherwise which voids any attempt of walking IO pagetables 2) Read-and-clear of Dirty IOVAs 3) Unmap vIOMMU-backed IOVAs and fetch its dirty state right-before-unmap. The series is still a WIP. The intend is to exercise the kernel side[0] aside from the selftests that provide some coverage. Comments, feedback, as always appreciated. Joao [0] https://lore.kernel.org/linux-iommu/20220428210933.3583-1-joao.m.martins@oracle.com/ Joao Martins (10): amd-iommu: Cache PTE/DTE info in IOTLB amd-iommu: Access/Dirty bit support intel-iommu: Cache PASID entry flags intel_iommu: Second Stage Access Dirty bit support linux-headers: import iommufd.h hwpt extensions vfio/iommufd: Add HWPT_SET_DIRTY support vfio/iommufd: Add HWPT_GET_DIRTY_IOVA support vfio/iommufd: Add IOAS_UNMAP_DIRTY support migration/dirtyrate: Expand dirty_bitmap to be tracked separately for devices hw/vfio: Add nr of dirty pages to tracepoints accel/kvm/kvm-all.c | 12 +++ hmp-commands.hx | 5 +- hw/i386/amd_iommu.c | 76 +++++++++++++- hw/i386/amd_iommu.h | 11 +- hw/i386/intel_iommu.c | 103 +++++++++++++++++-- hw/i386/intel_iommu_internal.h | 4 + hw/i386/trace-events | 4 + hw/iommufd/iommufd.c | 63 ++++++++++++ hw/iommufd/trace-events | 3 + hw/vfio/container.c | 20 +++- hw/vfio/iommufd.c | 179 ++++++++++++++++++++++++++++++++- hw/vfio/trace-events | 3 +- include/exec/memory.h | 10 +- include/hw/i386/intel_iommu.h | 1 + include/hw/iommufd/iommufd.h | 6 ++ linux-headers/linux/iommufd.h | 78 ++++++++++++++ migration/dirtyrate.c | 59 ++++++++--- migration/dirtyrate.h | 1 + qapi/migration.json | 15 +++ softmmu/memory.c | 5 + 20 files changed, 618 insertions(+), 40 deletions(-) -- 2.17.2
WARNING: multiple messages have this Message-ID (diff)
From: Joao Martins <joao.m.martins@oracle.com> To: qemu-devel@nongnu.org Cc: "John G . Johnson" <john.g.johnson@oracle.com>, kvm@vger.kernel.org, "Michael S. Tsirkin" <mst@redhat.com>, "Jason Wang" <jasowang@redhat.com>, "Peter Xu" <peterx@redhat.com>, "Joao Martins" <joao.m.martins@oracle.com>, "Eric Blake" <eblake@redhat.com>, "Yi Liu" <yi.l.liu@intel.com>, "Juan Quintela" <quintela@redhat.com>, "David Hildenbrand" <david@redhat.com>, "Markus Armbruster" <armbru@redhat.com>, "Nicolin Chen" <nicolinc@nvidia.com>, "Jason Gunthorpe" <jgg@nvidia.com>, "Kevin Tian" <kevin.tian@intel.com>, "Richard Henderson" <richard.henderson@linaro.org>, "Dr. David Alan Gilbert" <dgilbert@redhat.com>, "Eric Auger" <eric.auger@redhat.com>, "Alex Williamson" <alex.williamson@redhat.com>, "Thanos Makatos" <thanos.makatos@nutanix.com>, "Eduardo Habkost" <eduardo@habkost.net>, "Yishai Hadas" <yishaih@nvidia.com>, "Cornelia Huck" <cohuck@redhat.com>, "Philippe Mathieu-Daudé" <f4bug@amsat.org>, "Paolo Bonzini" <pbonzini@redhat.com> Subject: [PATCH RFC 00/10] hw/vfio, x86/iommu: IOMMUFD Dirty Tracking Date: Thu, 28 Apr 2022 22:13:41 +0100 [thread overview] Message-ID: <20220428211351.3897-1-joao.m.martins@oracle.com> (raw) This series expands IOMMUFD series from Yi and Eric into supporting IOMMU Dirty Tracking. It adds both the emulated x86 IOMMUs, as well as IOMMUFD support that exercises said emulation (or H/W). It is organized into: * Patches 1 - 4: x86 IOMMU emulation that performs dirty tracking, useful for a nested guest exercising the IOMMUFD kernel counterpart for coverage and development. The caching of the PASID PTE root flags and AMD DTE is not exactly the cleanest, still wondering about a better way without having to lookup context/DTE prior to IOTLB lookup. * Patches 5 - 9: IOMMUFD backend support for dirty tracking; Sadly this wasn't exactly tested with VF Live Migration, but it adds (last 2 patches) a way to measure dirty rate via HMP and QMP. The IOMMUFD kernel patches go into extent on what each of the ioctls do, albeit the workflow is relatively simple: 1) Toggling dirty tracking via HWPT_SET_DIRTY or get -ENOTSUPP otherwise which voids any attempt of walking IO pagetables 2) Read-and-clear of Dirty IOVAs 3) Unmap vIOMMU-backed IOVAs and fetch its dirty state right-before-unmap. The series is still a WIP. The intend is to exercise the kernel side[0] aside from the selftests that provide some coverage. Comments, feedback, as always appreciated. Joao [0] https://lore.kernel.org/linux-iommu/20220428210933.3583-1-joao.m.martins@oracle.com/ Joao Martins (10): amd-iommu: Cache PTE/DTE info in IOTLB amd-iommu: Access/Dirty bit support intel-iommu: Cache PASID entry flags intel_iommu: Second Stage Access Dirty bit support linux-headers: import iommufd.h hwpt extensions vfio/iommufd: Add HWPT_SET_DIRTY support vfio/iommufd: Add HWPT_GET_DIRTY_IOVA support vfio/iommufd: Add IOAS_UNMAP_DIRTY support migration/dirtyrate: Expand dirty_bitmap to be tracked separately for devices hw/vfio: Add nr of dirty pages to tracepoints accel/kvm/kvm-all.c | 12 +++ hmp-commands.hx | 5 +- hw/i386/amd_iommu.c | 76 +++++++++++++- hw/i386/amd_iommu.h | 11 +- hw/i386/intel_iommu.c | 103 +++++++++++++++++-- hw/i386/intel_iommu_internal.h | 4 + hw/i386/trace-events | 4 + hw/iommufd/iommufd.c | 63 ++++++++++++ hw/iommufd/trace-events | 3 + hw/vfio/container.c | 20 +++- hw/vfio/iommufd.c | 179 ++++++++++++++++++++++++++++++++- hw/vfio/trace-events | 3 +- include/exec/memory.h | 10 +- include/hw/i386/intel_iommu.h | 1 + include/hw/iommufd/iommufd.h | 6 ++ linux-headers/linux/iommufd.h | 78 ++++++++++++++ migration/dirtyrate.c | 59 ++++++++--- migration/dirtyrate.h | 1 + qapi/migration.json | 15 +++ softmmu/memory.c | 5 + 20 files changed, 618 insertions(+), 40 deletions(-) -- 2.17.2
next reply other threads:[~2022-04-28 21:14 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-28 21:13 Joao Martins [this message] 2022-04-28 21:13 ` [PATCH RFC 00/10] hw/vfio, x86/iommu: IOMMUFD Dirty Tracking Joao Martins 2022-04-28 21:13 ` [PATCH RFC 01/10] amd-iommu: Cache PTE/DTE info in IOTLB Joao Martins 2022-04-28 21:13 ` Joao Martins 2022-04-28 21:13 ` [PATCH RFC 02/10] amd-iommu: Access/Dirty bit support Joao Martins 2022-04-28 21:13 ` Joao Martins 2022-04-28 21:13 ` [PATCH RFC 03/10] intel-iommu: Cache PASID entry flags Joao Martins 2022-04-28 21:13 ` Joao Martins 2022-04-28 21:13 ` [PATCH RFC 04/10] intel_iommu: Second Stage Access Dirty bit support Joao Martins 2022-04-28 21:13 ` Joao Martins 2022-04-29 2:26 ` Jason Wang 2022-04-29 2:26 ` Jason Wang 2022-04-29 9:12 ` Joao Martins 2022-04-29 9:12 ` Joao Martins 2022-04-29 18:21 ` Peter Xu 2022-04-29 18:21 ` Peter Xu 2022-05-03 11:54 ` Joao Martins 2022-05-05 7:41 ` Jason Wang 2022-05-05 9:57 ` Joao Martins 2022-05-04 20:11 ` Peter Xu 2022-05-05 9:54 ` Joao Martins 2022-04-28 21:13 ` [PATCH RFC 05/10] linux-headers: import iommufd.h hwpt extensions Joao Martins 2022-04-28 21:13 ` Joao Martins 2022-04-28 21:13 ` [PATCH RFC 06/10] vfio/iommufd: Add HWPT_SET_DIRTY support Joao Martins 2022-04-28 21:13 ` Joao Martins 2022-04-28 21:13 ` [PATCH RFC 07/10] vfio/iommufd: Add HWPT_GET_DIRTY_IOVA support Joao Martins 2022-04-28 21:13 ` Joao Martins 2022-04-28 21:13 ` [PATCH RFC 08/10] vfio/iommufd: Add IOAS_UNMAP_DIRTY support Joao Martins 2022-04-28 21:13 ` Joao Martins 2022-04-28 21:13 ` [PATCH RFC 09/10] migration/dirtyrate: Expand dirty_bitmap to be tracked separately for devices Joao Martins 2022-04-28 21:13 ` Joao Martins 2022-05-02 12:54 ` Markus Armbruster 2022-05-02 12:54 ` Markus Armbruster 2022-05-02 14:35 ` Joao Martins 2022-05-02 14:35 ` Joao Martins 2022-04-28 21:13 ` [PATCH RFC 10/10] hw/vfio: Add nr of dirty pages to tracepoints Joao Martins 2022-04-28 21:13 ` Joao Martins
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=20220428211351.3897-1-joao.m.martins@oracle.com \ --to=joao.m.martins@oracle.com \ --cc=alex.williamson@redhat.com \ --cc=armbru@redhat.com \ --cc=cohuck@redhat.com \ --cc=david@redhat.com \ --cc=dgilbert@redhat.com \ --cc=eblake@redhat.com \ --cc=eduardo@habkost.net \ --cc=eric.auger@redhat.com \ --cc=f4bug@amsat.org \ --cc=jasowang@redhat.com \ --cc=jgg@nvidia.com \ --cc=john.g.johnson@oracle.com \ --cc=kevin.tian@intel.com \ --cc=kvm@vger.kernel.org \ --cc=marcel.apfelbaum@gmail.com \ --cc=mst@redhat.com \ --cc=nicolinc@nvidia.com \ --cc=pbonzini@redhat.com \ --cc=peterx@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=quintela@redhat.com \ --cc=richard.henderson@linaro.org \ --cc=thanos.makatos@nutanix.com \ --cc=yi.l.liu@intel.com \ --cc=yishaih@nvidia.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: linkBe 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.