On Mon, Jan 09, 2023 at 05:08:59PM +0800, Jason Wang wrote: > Either: > > 1) cropping in the memory core and remove the iommu cropping like > smmu_unmap_notifier_range() > > or > > 2) don't corp in the memory core but move smmu_unmap_notifier_range to > the core (still, a kind of implicit crop, since the function was > called without a range) > > 2) seems safer but I can go with 1 if you insist.
No strong opinion here, thanks for checking! I'm not exactly sure how it'll look like at last with 2), but so far either way sounds good. [...] > > It depends on how to define the "real invalidations". There're two places > > that can enlarge an invalidation, here I wanted to reference the case where > > e.g. a PSI is enlarged to a DSI. Even if that's the driver behavior, I > > wanted to make sure the qemu iommu notifiees are aware of the facts that > > unmap can be bigger than what it used to have mapped. > > Ok, I think the confusion came from "real invalidations". I think > there's no way for the device to know about the real invalidation > since the driver can enlarge it at will? If this is true, is this > better to say the UNAMP messages can cover the range that is not > mapped? I can reword, will repost soon. Thanks, -- Peter Xu
