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