Re: iommufd dirty page logging overview

[Jason Gunthorpe <jgg@nvidia.com>]

On Sun, Mar 20, 2022 at 03:34:30AM +0000, Tian, Kevin wrote:

> Thinking more the real problem is not related to *before* vs. *after*
> thing. :/ If Qemu itself doesn't maintain a virtual iotlb

It has to be after because only unmap guarentees that DMA is
completely stopped.

qemu must ensure it doesn't change the user VA to GPA mapping between
unmap and device fetch dirty, or install something else into that
IOVA.

Yes the physical PFNs can be shuffled around by the kernel due to the
lost page pin, but the logical dirty is really attached to qemu's
process VA (HVA), not the physical PFN.

It has to do this in all cases regardless of device or not - when it
unmaps the IOVA it must know what HVA it put there and translate the
dirties to that bitmap.

> given guest mappings for dirtied GIOVAs in the unmapped range
> already disappear at that point thus the path to find GIOVA->GPA->HVA
> is just broken.

qemu has to keep track of how IOVAs translate to HVAs - maybe we could
have the kernel return the HVA during unmap as well, it already stores
it, but this has some complications..

Fundamentally from a qemu perspective it is translating everything to
UVA because UVA is what the live migration machinery uses.

But this is all qemu problems and doesn't really help inform the
kernel API..

Jason