From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYNAt-0006ja-3l for qemu-devel@nongnu.org; Tue, 23 Feb 2016 19:19:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYNAp-0005eo-UK for qemu-devel@nongnu.org; Tue, 23 Feb 2016 19:19:27 -0500 Received: from mail-pf0-x230.google.com ([2607:f8b0:400e:c00::230]:35349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYNAp-0005eV-3r for qemu-devel@nongnu.org; Tue, 23 Feb 2016 19:19:23 -0500 Received: by mail-pf0-x230.google.com with SMTP id c10so1723653pfc.2 for ; Tue, 23 Feb 2016 16:19:23 -0800 (PST) References: <1456121379-13434-1-git-send-email-aik@ozlabs.ru> <20160222062631.GH2808@voom.fritz.box> <56CAF2B3.2030502@ozlabs.ru> <20160222121227.GN2808@voom.fritz.box> <56CBBFD7.3050806@ozlabs.ru> <20160223062056.GU2808@voom.fritz.box> <56CC1FA3.5020003@ozlabs.ru> <56CC2CE9.6030605@redhat.com> From: Alexey Kardashevskiy Message-ID: <56CCF706.30103@ozlabs.ru> Date: Wed, 24 Feb 2016 11:19:18 +1100 MIME-Version: 1.0 In-Reply-To: <56CC2CE9.6030605@redhat.com> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qemu] memory: Fix IOMMU replay base address List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , David Gibson Cc: qemu-devel@nongnu.org On 02/23/2016 08:56 PM, Paolo Bonzini wrote: > > > On 23/02/2016 10:00, Alexey Kardashevskiy wrote: >>>> >>>> tce = tcet->table[addr >> tcet->page_shift]; >>>> - ret.iova = addr & page_mask; >>>> + ret.iova = (addr + iommu->addr) & page_mask; >>>> ret.translated_addr = tce & page_mask; >>> >>> I wondered about that change, but I'd have to look closer to see if >>> the iova field here is expected to be relative to the MR as well. It >>> would be oddly inconsistent if it wasn't. >> >> It is relative and it does not make sense as there is no source MR/AS in >> iotlb (only target AS) so there is no use in such iova. > > ret.iova should be relative to the source AS (i.e. even if a 32-bit > IOMMU region translates between 4GB and 8GB, ret.iova should have bits > 32-63 set to 0). In my test branch with 2 DMA windows I have such PHB AS: address-space: pci@800000020000000 0000000000000000-ffffffffffffffff (prio 0, RW): pci@800000020000000.iommu-root 0000000000000000-ffffffffffffffff (prio 0, RW): tce-root-80000001 0800000000000000-08000000ffffffff (prio 0, RW): tce-iommu-80000001 0000000000000000-ffffffffffffffff (prio 0, RW): tce-root-80000000 0000000000000000-000000003fffffff (prio 0, RW): tce-iommu-80000000 0000040000000000-000004000000ffff (prio 0, RW): msi The source AS is 0..(u64)-1. iotlb.iova from spapr_tce_translate_iommu(tce-root-80000001) will be relative to 0800000000000000 which is not source AS. What do I miss here? > > So there is a problem in vfio_iommu_map_notify: > > ret = vfio_dma_map(container, iotlb->iova, > iotlb->addr_mask + 1, vaddr, > !(iotlb->perm & IOMMU_WO) || mr->readonly); > > I think that, in vfio_listener_region_add, the iova variable should be > stored in VFIOGuestIOMMU for use in vfio_iommu_map_notify. > > ret.translated_addr should be relative to the target AS, which VFIO > assumes to be address_space_memory. That is perfectly fine - there is iotlb.target_as. -- Alexey