On Wed, Mar 16, 2022 at 11:29:42PM +0000, Thanos Makatos wrote: > We're interested in adopting the new migration v2 interface and the > new dirty page logging for /dev/iommufd in an out-of-process device > emulation protocol [1]. Although it's purely userspace, we do want > to stay close to the new API(s) being proposed for many reasons, > mainly to re-use the QEMU implementation. The migration-related > changes are relatively straightforward, I'm more interested in the > dirty page logging. I've started reading the relevant email threads > and my impression so far is that the details are still being > decided? Yes Joao has made the most progress so far > there a rough idea of how the new dirty page logging will look like? > Is this already explained in the email threads an I missed it? I'm hoping to get something to show in the next few weeks, but what I've talked about previously is to have two things: 1) Control and reporting of dirty tracking via the system IOMMU through the iommu_domain interface exposed by iommufd 2) Control and reporting of dirty tracking via a VFIO migration capable device's internal tracking through a VFIO_DEVICE_FEATURE interface similar to the v2 migration interface The two APIs would be semantically very similar but target different HW blocks. Userspace would be in charge to decide which dirty tracker to use and how to configure it. I'm expecting that semantically everything would look like the current dirty tracking draft, where you start/stop tracking then read&clear a bitmap for a range of IOVA and integrate that with the dirty data from KVM. Jason
