On 5 June 2018 at 15:26, Peter Xu <pet...@redhat.com> wrote: > So we have a requirement that we want to send an invalidation for > either (1) unspecified, or (2) secure=1. We can't do that with a > single MemTxAttrs. > > Could we just notify twice? One with unspecified=1 and one with > secure=1? Is this (reduce the calls to notify functions) the major > reason we introduce this IOMMU index idea into the memory API (besides > "avoid possible programming error" you mentioned in IRC discussion)?
How would you handle "this changes mappings for txattrs where unspecified == 0 && secure == 0" ? How does the notifier registering API say what it's interested in? In the exec.c code that deals with sending TCG transactions through IOMMUs, if I have to register a notifier for every possible TCG transaction attribute I ever see, that's a lot of unnecessary notifiers. > Again, I think the more critical question would be whether we can pass > in MemTxAttrs into translate(), and whether we can avoid introducing > this IOMMU index idea into the memory API layer... For example, would > it add complexity to other architectures without much benefit? I think the fundamental difference in our points of view here is that I see the IOMMU index as *reducing* complexity, not adding it. Yes, it is an extra level of indirection, but I think it helps us express a useful concept. The patches you've sent here seem to me to be adding extra complexity to the notifier API and the core code which isn't required in the patch set that I sent. thanks -- PMM
