Re: [Qemu-devel] [PATCH 2/3] memory: add iommu_notify_flag

[Peter Xu]

On Wed, Sep 07, 2016 at 03:44:19PM +1000, David Gibson wrote:
> > 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.

Yeah... For MAP/UNMAP, it is strange in another way: e.g. for vhost,
it doesn't care about map/unmap, it cares about invalidated cache. So
IIUC this is a question about "naming" but not the implementations...
I suppose it is really a matter of taste, and both work for me (either
INVALIDATION/CHANGE or UNMAP/MAP).

Thanks,

-- peterx