Re: iommufd dirty page logging overview

[Jason Gunthorpe <jgg@nvidia.com>]

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