From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38352) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFlYe-0002qr-16 for qemu-devel@nongnu.org; Wed, 22 Jun 2016 13:03:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFlYY-0002If-Lr for qemu-devel@nongnu.org; Wed, 22 Jun 2016 13:03:18 -0400 Date: Wed, 22 Jun 2016 11:03:18 -0600 From: Alex Williamson Message-ID: <20160622110318.6fba16f3@t450s.home> In-Reply-To: <20160621065017.GC17957@voom.fritz.box> References: <1466471645-5396-1-git-send-email-aik@ozlabs.ru> <1466471645-5396-4-git-send-email-aik@ozlabs.ru> <20160621065017.GC17957@voom.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH qemu v18 3/5] vfio: Add host side DMA window capabilities List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: Alexey Kardashevskiy , qemu-devel@nongnu.org, qemu-ppc@nongnu.org On Tue, 21 Jun 2016 16:50:17 +1000 David Gibson wrote: > On Tue, Jun 21, 2016 at 11:14:03AM +1000, Alexey Kardashevskiy wrote: > > There are going to be multiple IOMMUs per a container. This moves > > the single host IOMMU parameter set to a list of VFIOHostDMAWindow. > > > > This should cause no behavioral change and will be used later by > > the SPAPR TCE IOMMU v2 which will also add a vfio_host_win_del() helper. > > > > Signed-off-by: Alexey Kardashevskiy > > Reviewed-by: David Gibson > > Looks ok to me. Again, Alex, your tree or mine? I gave the previous patch a nak, it needs a respin, but this one looks ok. I don't currently have anything pending that would conflict with this, afaik, so it's ok with me if you want to pull it through your tree. I'll ack the respin. > One minor point.. > [snip] > > @@ -878,17 +908,14 @@ static int vfio_connect_container(VFIOGroup *group, AddressSpace *as) > > * existing Type1 IOMMUs generally support any IOVA we're > > * going to actually try in practice. > > */ > > - container->min_iova = 0; > > - container->max_iova = (hwaddr)-1; > > - > > - /* Assume just 4K IOVA page size */ > > - container->iova_pgsizes = 0x1000; > > info.argsz = sizeof(info); > > ret = ioctl(fd, VFIO_IOMMU_GET_INFO, &info); > > /* Ignore errors */ > > - if ((ret == 0) && (info.flags & VFIO_IOMMU_INFO_PGSIZES)) { > > - container->iova_pgsizes = info.iova_pgsizes; > > + if (ret || !(info.flags & VFIO_IOMMU_INFO_PGSIZES)) { > > + /* Assume 4k IOVA page size */ > > + info.iova_pgsizes = 4096; > > } > > + vfio_host_win_add(container, 0, (hwaddr)-1, info.iova_pgsizes); > > I don't think it needs to hold this patch up, but at some point we > should work out the real range covered by the x86 IOMMU tables and put > that in here. I'm pretty sure it won't actually be 2^64-1. Between this patch, some work that Eric is doing that would allow us to exclude the MSI range, and the capability chains that we can add to the IOMMU_GET_INFO ioctl to describe both the extent and the reserved MSI area, I think we're getting close to being able to do that. On AMD I think we do have a full 64bit address space, but VT-d is definitely not. Thanks, Alex