Re: [PATCH] intel-iommu: Document iova_tree

[Peter Xu <peterx@redhat.com>]

On Tue, Dec 06, 2022 at 02:06:54PM +0100, Eric Auger wrote:
> >>> +     * current VTD address space, because all UNMAP (including iotlb or
> >>> +     * dev-iotlb) events can be transparently delivered to !MAP iommu
> >>> +     * notifiers.
> >> because all UNMAP notifications (iotlb or dev-iotlb) can be triggered
> >> directly, as opposed to MAP notifications. (?)
> > What I wanted to say is any PSI or DSI messages we got from the guest can
> > be transparently delivered to QEMU's iommu notifiers.  I'm not sure
> > "triggered directly" best describe the case here.
> yes "transparently delivered" is OK. Or "guest invalidate commands can
> be directly passed to the IOMMU UNMAP notifiers without any further
> reshuffling". But that's nitpicking.

Will do.

> >
> > PSI: Page Selective Invalidations
> > DSI: Domain Selective Invalidations
> >
> > Sorry to mention these terms again, but that's really what the "transparent
> > delivery" means here - we get the PSI/DSI messages, then we notify with the
> > same ranges in IOMMU notifiers.  They're not the same concept but we do
> > that transparently without changing the core of the messages.
> >
> > Maybe I should spell out "!MAP" as "UNMAP-only"?  Would that help?
> yeah those are unmap notifiers if I am correct.
> >
> >>> +     *
> >>> +     * The tree OTOH is required for MAP typed iommu notifiers for a few
> >>> +     * reasons.
> >>> +     *
> >>> +     * Firstly, there's no way to identify whether an PSI event is MAP or
> >> maybe give the decryption of the 'PSI' and 'DSI" acronyms once ;-)
> > Please see above. :)
> ok thanks
> >
> > These are VT-d terms used in multiple places in the .[ch] files, I assume
> > I'll just keep using them because otherwise I'll need to comment them
> > everytime we use any PSI/DSI terms.  It might become an overkill I'm afraid.
> OK maybe just using the full terminology once is enough.

Ok, I'll add them.

Thanks Eric.

-- 
Peter Xu