From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Coquelin Subject: Re: [PATCH 07/10] linuxapp/eal_vfio: honor iova mode before mapping Date: Wed, 5 Jul 2017 11:14:01 +0200 Message-ID: <730e333b-a9ab-df8b-cf7a-1e0186c6152d@redhat.com> References: <20170608110513.22548-1-santosh.shukla@caviumnetworks.com> <20170608110513.22548-8-santosh.shukla@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com, shreyansh.jain@nxp.com, gaetan.rivet@6wind.com To: Santosh Shukla , thomas@monjalon.net, bruce.richardson@intel.com, dev@dpdk.org Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 10C102C8 for ; Wed, 5 Jul 2017 11:14:08 +0200 (CEST) In-Reply-To: <20170608110513.22548-8-santosh.shukla@caviumnetworks.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 06/08/2017 01:05 PM, Santosh Shukla wrote: > Check iova mode and accordingly map iova to pa or va. > > Signed-off-by: Santosh Shukla > Signed-off-by: Jerin Jacob > --- > lib/librte_eal/linuxapp/eal/eal_vfio.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/lib/librte_eal/linuxapp/eal/eal_vfio.c b/lib/librte_eal/linuxapp/eal/eal_vfio.c > index 04914406f..348b7a7f4 100644 > --- a/lib/librte_eal/linuxapp/eal/eal_vfio.c > +++ b/lib/librte_eal/linuxapp/eal/eal_vfio.c > @@ -706,7 +706,10 @@ vfio_type1_dma_map(int vfio_container_fd) > dma_map.argsz = sizeof(struct vfio_iommu_type1_dma_map); > dma_map.vaddr = ms[i].addr_64; > dma_map.size = ms[i].len; > - dma_map.iova = ms[i].phys_addr; > + if (rte_eal_iova_mode() == RTE_IOVA_VA) > + dma_map.iova = dma_map.vaddr; > + else > + dma_map.iova = ms[i].phys_addr; > dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE; > IIUC, it is changing default behavior for VFIO devices. I see a possible problem, but I'm not sure the case is valid. Imagine you have two devices in the iommu group, and the two devices are used in separate processes. Each process could try two different physical addresses at the same virtual address, and so the second map would fail. By using physical addresses, you are safe against this problem. Any thoughts? Cheers, Maxime