From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39116) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ubsps-0001aO-Vp for qemu-devel@nongnu.org; Mon, 13 May 2013 09:30:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ubspq-0003UE-Jg for qemu-devel@nongnu.org; Mon, 13 May 2013 09:30:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39119) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ubspq-0003Tz-CW for qemu-devel@nongnu.org; Mon, 13 May 2013 09:30:38 -0400 Message-ID: <5190EAF2.6020606@redhat.com> Date: Mon, 13 May 2013 15:30:26 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1368442465-14363-1-git-send-email-david@gibson.dropbear.id.au> <5190DB42.10002@redhat.com> <20130513131348.GD14944@truffula.fritz.box> In-Reply-To: <20130513131348.GD14944@truffula.fritz.box> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [0/8] RFC: VFIO and guest side IOMMUs, revisited List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: aik@ozlabs.ru, alex.williamson@redhat.com, mst@redhat.com, qemu-devel@nongnu.org, agraf@suse.de -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 13/05/2013 15:13, David Gibson ha scritto: > On Mon, May 13, 2013 at 02:23:30PM +0200, Paolo Bonzini wrote: >> Il 13/05/2013 12:54, David Gibson ha scritto: >>> Specifically the way the iommu is determined from a callback >>> in the PCIBus means that it won't be assigned for devices under >>> a PCI-PCI bridge. >> >> Right. I saw the report from Alexey, but I am a bit wary of >> touching it because it's not a regression. In fact there is >> even a FIXME for it: >> >> /* FIXME: inherit memory region from bus creator */ > > Uh.. sort of. > >> Perhaps we can make pci_iommu_as a Bus method, where the default >> implementation looks up along the chain, and the end of the >> recursion is in SysBus or in PCI buses that have set the >> callback. > > So, this is complicated by the fact that there are two cases, and > they can both be found in existing hardware. > > 1) One is where devices behind the bridge are not visible / > differentiable to the IOMMU, and so effectively all their DMAs > originate from the bridge device itself. In this case the correct > thing is to give all devices under the bridge the same DMA > AddressSpace as the bridge device, as suggested by the FIXME. This > will be typical behaviour for PCI-E to PCI bridges. > > 2) The other case is where the bridge passes through RIDs, so that > the IOMMU can still differentiate devices behind it. For this > case, we really want the hook to be in the host bridge / root bus, > and it can make a decision based on the full bus/dev/fn > information. This will be typical for PCI-E to PCI-E bridges (or > switches or nexuses or whatever they're usually called for PCI-E). > This case will be very important as we start to model newer PCI-E > based machines by default, where typically *all* devices are > behind a logical p2p bridge inside the root complex (but are still > differentiable by the Intel IOMMU amongst others). > > I'm not sure at this stage how to properly handle both cases. Suppose you have a host bridge pci_bus0 and a PCIE->PCIE bridge pci_bus1. pci_bus1 does not define a IOMMU callback, pci_bus0 does. Would it work to use the PCIBus callback provided by pci_bus0, but invoke it as pci_bus0->iommu_fn(pci_bus1, pci_bus0->iommu_opaque, devfn) ? Paolo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRkOryAAoJEBvWZb6bTYbydNoQAIbBuyYTm0MvERXOFb7YkTQC oe0B09CN2fdnWIeacl7taa1/5Pe0hY7JpuLSQCD1/4P4ovKPOROJ652BxSdDmBtG cZTmqG35ScfhM8ES66voKMO/o7LhPiJ3OLoUUNaVvEMmXCq4ag6LQd42RMyQVGtu hyjA5thPRV7u7/m0+iPxALxegvicxqQk/IkN5nRtXeO0LK78o5TxXX/3qMU1k7Rh FqfxbfSA0ceFu5PUtm5TnpwArVYJUZJfJZuMpr+B8Ub5zoo0nt6nfBZG7P5Sk7Aw MN54CfvJ/3roAS4BwFNBYbYV6ZxW6P99yUnlMcsrmUXhjsGfVxiCz7pqhTUuFnyQ O620UTSH3rIrdEFalfrG1mZSvf550b4cc1PW/+TAd2d2uBzEq2wb/vOW9vr6/EXB /Y7nLLHeik12sWg1bNklhnr4UYQ9FBzAo6duWCgw42OIggKSuOzRWxU4vFpX/abb BVX/61zSTujh6qfnQdWOKQuvYlcZUI+sqHF3SUdYH7yaE+gH0PJea3vqg3H2jQgT ktVjNuxQE2P+lL8C+VfHGoTRjZ0OgAgAo19qrCzdwX6kJocKU5apqZJ/qOvHatKq ZoOyfnwO/HUJ6wfP1INLvgNvOIbHyQ98fIVgFtmOQbES/NRVpf0y1K+opKkJ+BXZ kmJHRiIUcH0VnLYTmaVr =2jMC -----END PGP SIGNATURE-----