On Tue, Sep 06, 2016 at 06:31:42PM +0800, Peter Xu wrote:
> On Tue, Sep 06, 2016 at 10:19:14AM +0200, Paolo Bonzini wrote:
> > 
> > 
> > On 06/09/2016 10:17, Peter Xu wrote:
> > > After knowing the possibility that the two consumers might be
> > > mixturely used in the future (as David has mentioned), I'd vote for a
> > > bitmask for notification type:
> > > 
> > >     IOMMU_NOTIFIER_NONE = 0,
> > >     IOMMU_NOTIFIER_INVALIDATION = 1,
> > >     IOMMU_NOTIFIER_ADDITION = 2,
> > 
> > ADDITION really should be "CHANGE" I think, so what about
> > IOMMU_NOTIFIER_INVALIDATE and IOMMU_NOTIFIER_CHANGE?
> 
> For "CHANGE", it sounds like a unmap() + a map(). However I'd say
> "ADDITION" is nowhere better...

Right.. this brings up a good point.

Changing a mapping (i.e. overwriting an existing mapping with a
different one) would also need notification, even on x86, no?  Since
it implicitly invalidates the previous mapping.

I'm guessing the guest will avoid this by always unmapping before it
maps.  We still need to consider this possibility when designing the
notifier interface though.

It seems the real notification triggers here are:
    * map - something is mapped which previously wasn't
    * unmap - something is no longer mapped which was before

Note that whether the second needs to be triggered depends on the
*previous* state of that IOBA range, *not* on the permissions of the
new mapping (if any).

A "change" - replacing one mapping with another should count as both a
"map" and "unmap" event.

> 
> Will use "CHANGE".
> 
> > 
> > For VFIO, would the "invalidate" and "add" callbacks use the same code
> > or different?
> 
> Currently vfio_iommu_map_notify() should be handling both.
> 
> Thanks,
> 
> -- peterx
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson