Re: [PATCH v3] intel-iommu: Document iova_tree

[Peter Xu <peterx@redhat.com>]

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