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