From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933500AbcKKPrK (ORCPT ); Fri, 11 Nov 2016 10:47:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56744 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932818AbcKKPrJ (ORCPT ); Fri, 11 Nov 2016 10:47:09 -0500 Subject: Re: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback To: Joerg Roedel References: <1478258646-3117-1-git-send-email-eric.auger@redhat.com> <1478258646-3117-9-git-send-email-eric.auger@redhat.com> <20161110154606.GH2078@8bytes.org> <04ed9694-707d-260b-70c6-f367d292ceca@redhat.com> <20161110161331.GJ2078@8bytes.org> <20161111114223.GP2078@8bytes.org> Cc: drjones@redhat.com, jason@lakedaemon.net, kvm@vger.kernel.org, marc.zyngier@arm.com, punit.agrawal@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, diana.craciun@nxp.com, alex.williamson@redhat.com, pranav.sawargaonkar@gmail.com, linux-arm-kernel@lists.infradead.org, tglx@linutronix.de, robin.murphy@arm.com, christoffer.dall@linaro.org, eric.auger.pro@gmail.com From: Auger Eric Message-ID: <79da09b8-ac1e-cebf-5393-7d67f002b3e3@redhat.com> Date: Fri, 11 Nov 2016 16:47:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161111114223.GP2078@8bytes.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 11 Nov 2016 15:47:08 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Joerg, On 11/11/2016 12:42, Joerg Roedel wrote: > On Thu, Nov 10, 2016 at 07:00:52PM +0100, Auger Eric wrote: >> GICv2m and GICV3 ITS use dma-mapping iommu_dma_map_msi_msg to allocate >> an MSI IOVA on-demand. > > Yes, and it the right thing to do there because as a DMA-API > implementation the dma-iommu code cares about the address space > allocation. > > As I understand it this is different in your case, as someone else is > defining the address space layout. So why do you need to allocate it > yourself? Effectively in passthrough use case, the userspace defines the address space layout and maps guest RAM PA=IOVA to PAs (using VFIO_IOMMU_MAP_DMA). But this address space does not comprise the MSI IOVAs. Userspace does not care about MSI IOMMU mapping. So the MSI IOVA region must be allocated by either the VFIO driver or the IOMMU driver I think. Who else could initialize the IOVA allocator domain? That's true that we have a mix of unmanaged addresses and "managed" addresses which is not neat. But how to manage otherwise? Thanks Eric > > > Joerg > From mboxrd@z Thu Jan 1 00:00:00 1970 From: eric.auger@redhat.com (Auger Eric) Date: Fri, 11 Nov 2016 16:47:01 +0100 Subject: [RFC v2 8/8] iommu/arm-smmu: implement add_reserved_regions callback In-Reply-To: <20161111114223.GP2078@8bytes.org> References: <1478258646-3117-1-git-send-email-eric.auger@redhat.com> <1478258646-3117-9-git-send-email-eric.auger@redhat.com> <20161110154606.GH2078@8bytes.org> <04ed9694-707d-260b-70c6-f367d292ceca@redhat.com> <20161110161331.GJ2078@8bytes.org> <20161111114223.GP2078@8bytes.org> Message-ID: <79da09b8-ac1e-cebf-5393-7d67f002b3e3@redhat.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Joerg, On 11/11/2016 12:42, Joerg Roedel wrote: > On Thu, Nov 10, 2016 at 07:00:52PM +0100, Auger Eric wrote: >> GICv2m and GICV3 ITS use dma-mapping iommu_dma_map_msi_msg to allocate >> an MSI IOVA on-demand. > > Yes, and it the right thing to do there because as a DMA-API > implementation the dma-iommu code cares about the address space > allocation. > > As I understand it this is different in your case, as someone else is > defining the address space layout. So why do you need to allocate it > yourself? Effectively in passthrough use case, the userspace defines the address space layout and maps guest RAM PA=IOVA to PAs (using VFIO_IOMMU_MAP_DMA). But this address space does not comprise the MSI IOVAs. Userspace does not care about MSI IOMMU mapping. So the MSI IOVA region must be allocated by either the VFIO driver or the IOMMU driver I think. Who else could initialize the IOVA allocator domain? That's true that we have a mix of unmanaged addresses and "managed" addresses which is not neat. But how to manage otherwise? Thanks Eric > > > Joerg >