On Thu, Oct 27, 2022, Marc Zyngier wrote: > On Thu, 27 Oct 2022 18:44:51 +0100, > Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > On Thu, Oct 27, 2022, Marc Zyngier wrote: > > > But in the long run, with dirty bits being collected from the IOMMU > > > page tables or directly from devices, we will need a way to reconcile > > > the dirty tracking. The above doesn't quite cut it, unfortunately. > > > > Oooh, are you referring to IOMMU page tables and devices _in the > > guest_? E.g. if KVM itself were to emulate a vIOMMU, then KVM would > > be responsible for updating dirty bits in the vIOMMU page tables. > > No. I'm talking about the *physical* IOMMU, which is (with the correct > architecture revision and feature set) capable of providing its own > set of dirty bits, on a per-device, per-PTE basis. Once we enable > that, we'll need to be able to sink these bits into the bitmap and > provide a unified view of the dirty state to userspace. Isn't that already handled by VFIO, e.g. via VFIO_IOMMU_DIRTY_PAGES? There may be "duplicate" information if a page is dirty in both the IOMMU page tables and the CPU page tables, but that's ok in that the worst case scenario is that the VMM performs a redundant unnecessary transfer. A unified dirty bitmap would potentially reduce the memory footprint needed for dirty logging, but presumably IOMMU-mapped memory is a small subset of CPU-mapped memory in most use cases. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
