From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40047) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1avhe5-0002tr-II for qemu-devel@nongnu.org; Thu, 28 Apr 2016 04:50:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1avhe0-0007Sq-EO for qemu-devel@nongnu.org; Thu, 28 Apr 2016 04:50:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1avhe0-0007SX-6t for qemu-devel@nongnu.org; Thu, 28 Apr 2016 04:49:56 -0400 Date: Thu, 28 Apr 2016 16:49:49 +0800 From: Peter Xu Message-ID: <20160428084949.GG20143@pxdev.xzpeter.org> References: <1461827144-6937-1-git-send-email-peterx@redhat.com> <1461827144-6937-16-git-send-email-peterx@redhat.com> <5721BB09.2030302@web.de> <20160428082915.GF20143@pxdev.xzpeter.org> <5721CB83.4080005@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5721CB83.4080005@web.de> Subject: Re: [Qemu-devel] [PATCH v5 15/18] intel_iommu: introduce IEC notifiers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel@nongnu.org, imammedo@redhat.com, rth@twiddle.net, ehabkost@redhat.com, jasowang@redhat.com, marcel@redhat.com, mst@redhat.com, pbonzini@redhat.com, rkrcmar@redhat.com, alex.williamson@redhat.com, wexu@redhat.com, David kiarie 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