Re: [Qemu-devel] [PATCH v5 15/18] intel_iommu: introduce IEC notifiers

[Peter Xu]

On Thu, Apr 28, 2016 at 10:36:19AM +0200, Jan Kiszka wrote:
> On 2016-04-28 10:29, Peter Xu wrote:
> > On Thu, Apr 28, 2016 at 09:26:01AM +0200, Jan Kiszka wrote:
> >> On 2016-04-28 09:05, Peter Xu wrote:
> >>> This patch introduces Intel VT-d IEC (Interrupt Entry Cache)
> >>> invalidation notifier list. When vIOMMU receives IEC invalidate request,
> >>> all the registered units will be notified with specific invalidation
> >>> requests.
> >>
> >> This should be designed to be IOMMU-agnostic, i.e. become reusable for
> >> the AMD implementation. I suspect we will have the same need for route
> >> invalidations there as well...
> > 
> > Yes possibly...
> > 
> > I feel like there are lots of things that can be shared between
> > Intel and AMD IOMMUs. I just do not know what is the most suitable
> > "extent" that we should abstract these shared functionalities
> > between the two, and how.
> 
> A rough indicator: if you add something that has "vtd" in its name to
> non-vtd code, think twice about some reusable abstraction ;). So,
> something like "vtd_get_iommu" could already be named and designed to
> have two provides (e.g. allow an IOMMU to register itself as provider,
> return that registered instance(s) when requested).

Yes, thanks for the hints. :)

Before that, I was considering that the AMD guy who is going to add
its support will better consider this and finally make sure the two
coops well (anyway, I know nothing about AMD IOMMU before reading
recent patches, and there is still no amd_iommu.c yet for me to read
at..). But you are right, best to start consider it from the very
beginning.

> 
> > 
> > For example, AFAIU, a better solution for current IOMMU
> > codes (including Intel and AMD) is to provide a common framework
> > (like...  X86IOMMU?), abstract these shared things out into a
> > framework, like per device name spaces, iotlb, IEC notifications,
> > etc... However, that will need a lot of further work. Also, I still
> > do not know whether this is a good idea even in the future.
> > 
> > So, will this be a good point that we start to think about common
> > code blocks for both Intel and AMD IOMMU?
> 
> The core iommu code can still be refactored later on. I'm now more
> concerned about the hooks you add to generic code, see above.

Will try to make them look better in v6. Hopefully there will have
no vtd_*() in common codes. ;)

Thanks!

-- peterx