From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moutng.kundenserver.de ([212.227.17.8]:59088 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753157Ab0G2LZz (ORCPT ); Thu, 29 Jul 2010 07:25:55 -0400 From: Arnd Bergmann Subject: Re: [PATCH 1/2] arm: msm: Add System MMU support. Date: Thu, 29 Jul 2010 13:25:47 +0200 References: <20100729090607.GN26098@amd.com> <20100729184336N.fujita.tomonori@lab.ntt.co.jp> <20100729100108.GQ26098@amd.com> In-Reply-To: <20100729100108.GQ26098@amd.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201007291325.48129.arnd@arndb.de> Sender: linux-arm-msm-owner@vger.kernel.org List-ID: To: "Roedel, Joerg" Cc: FUJITA Tomonori , "stepanm@codeaurora.org" , "linux-arm-kernel@lists.infradead.org" , "linux-arm-msm@vger.kernel.org" , "dwalker@codeaurora.org" , "linux-kernel@vger.kernel.org" On Thursday 29 July 2010, Roedel, Joerg wrote: > > You designed it for what you need at the time. It should have been > > named appropriately to avoid confusion. Later, when we actually > > understand what other IOMMUs need, we can evolve the specific API for > > generic purposes. Then we can rename the API to more generic. > > At the time the iommu-api was written is was generic enough for what we > had. So it was designed as an generic API. At this point in time nobody > knew what the future requirements would we. So today it turns out that > it is not generic enough anymore for latest hardware. The logical > consequence is to fix this in the iommu-api. Well, I think the real question is why we have two APIs that both claim to work with IOMMUs in a generic way and how we could unify the two. The Intel and AMD IOMMU drivers currently register at both the DMA API and the IOMMU API. The first one is used by everything except KVM and the second is only used by KVM. I really think we should not extend the (KVM) IOMMU API further but just use the generic DMA mapping api for KVM and extend it as necessary. It already has the concept of cache coherency and mapping/unmapping that are in the IOMMU API and could be extended to support domains as well, through the use of dma_attrs. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Thu, 29 Jul 2010 13:25:47 +0200 Subject: [PATCH 1/2] arm: msm: Add System MMU support. In-Reply-To: <20100729100108.GQ26098@amd.com> References: <20100729090607.GN26098@amd.com> <20100729184336N.fujita.tomonori@lab.ntt.co.jp> <20100729100108.GQ26098@amd.com> Message-ID: <201007291325.48129.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thursday 29 July 2010, Roedel, Joerg wrote: > > You designed it for what you need at the time. It should have been > > named appropriately to avoid confusion. Later, when we actually > > understand what other IOMMUs need, we can evolve the specific API for > > generic purposes. Then we can rename the API to more generic. > > At the time the iommu-api was written is was generic enough for what we > had. So it was designed as an generic API. At this point in time nobody > knew what the future requirements would we. So today it turns out that > it is not generic enough anymore for latest hardware. The logical > consequence is to fix this in the iommu-api. Well, I think the real question is why we have two APIs that both claim to work with IOMMUs in a generic way and how we could unify the two. The Intel and AMD IOMMU drivers currently register at both the DMA API and the IOMMU API. The first one is used by everything except KVM and the second is only used by KVM. I really think we should not extend the (KVM) IOMMU API further but just use the generic DMA mapping api for KVM and extend it as necessary. It already has the concept of cache coherency and mapping/unmapping that are in the IOMMU API and could be extended to support domains as well, through the use of dma_attrs. Arnd