On 3/1/22 13:54, Jason Gunthorpe wrote: > On Tue, Mar 01, 2022 at 01:06:30PM +0000, Joao Martins wrote: > >> I concur with you in the above but I don't mean it like a multiplexer. >> Rather, mimicking the general nature of feature bits in the protection domain >> (or the hw pagetable abstraction). So hypothetically for every bit ... if you >> wanted to create yet another op that just flips a bit of the >> DTEs/PASID-table/CD it would be an excessive use of callbacks to get >> to in the iommu_domain_ops if they all set do the same thing. >> Right now it's only Dirty (Access bit I don't see immediate use for it >> right now) bits, but could there be more? Perhaps this is something to >> think about. > > Not sure it matters :) > Hehe, most likely it doesn't :) >>> One problem with this is that devices that don't support dynamic >>> tracking are stuck in vIOMMU cases where the IOAS will have some tiny >>> set of all memory mapped. >>> >> Sorry to be pedantic, when you say 'dynamic tracking' for you it just means >> that you have no limitation of ranges and fw/hw can cope with being fed of >> 'new-ranges' to enable dirty-tracking. > > Yes, the ranges can change once the tracking starts, like the normal > IOMMU can do > > We are looking at devices where the HW can track a range at the start > of tracking and that range cannot change over time. > > So, we need to track the whole guest memory and some extra for memory > hot plug, not just the currently viommu mapped things. I'm aware of the guest memmap accounting foo, so I was already factoring that in the equation. I was just mainly grokking at hardware limitations you are coming from to be captured in these future VFIO extensions. Tracking the max possible GPA (as you hinted earlier) could solve the two natures of write-tracking, also given that the IOMMU ultimately protects what's really allowed to be DMA-written to. Unless such tracking-bitmap is placed on device memory, where space probably needs to be more carefully managed. Anyways, thanks for the insights!
