From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WoYZ2-0003c8-D2 for qemu-devel@nongnu.org; Sun, 25 May 2014 09:34:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WoYYy-0001oB-By for qemu-devel@nongnu.org; Sun, 25 May 2014 09:34:12 -0400 Date: Sun, 25 May 2014 23:36:43 +1000 From: David Gibson Message-ID: <20140525133643.GA15140@voom.fritz.box> References: <1400821160-25258-1-git-send-email-aik@ozlabs.ru> <1400821160-25258-6-git-send-email-aik@ozlabs.ru> <537F30C7.3010704@suse.de> <537F392B.7020209@ozlabs.ru> <537F3972.9080907@suse.de> <537F7473.6000200@ozlabs.ru> <537FBA8A.6020704@suse.de> <53800E02.6050400@ozlabs.ru> <5381C2F4.8040402@suse.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <5381C2F4.8040402@suse.de> Subject: Re: [Qemu-devel] [PATCH v6 5/7] vfio: Introduce VFIO address spaces List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Alexey Kardashevskiy , Alex Williamson , qemu-ppc@nongnu.org, qemu-devel@nongnu.org --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 25, 2014 at 12:16:20PM +0200, Alexander Graf wrote: >=20 > On 24.05.14 05:12, Alexey Kardashevskiy wrote: > >On 05/24/2014 07:15 AM, Alexander Graf wrote: > >>On 23.05.14 18:16, Alexey Kardashevskiy wrote: > >>>On 05/23/2014 10:05 PM, Alexander Graf wrote: > >>>>On 23.05.14 14:03, Alexey Kardashevskiy wrote: > >>>>>On 05/23/2014 09:28 PM, Alexander Graf wrote: > >>>>>>On 23.05.14 06:59, Alexey Kardashevskiy wrote: > >>>>>>>From: David Gibson > >>>>>>> > >>>>>>>The only model so far supported for VFIO passthrough devices is the > >>>>>>>model > >>>>>>>usually used on x86, where all of the guest's RAM is mapped into t= he > >>>>>>>(host) IOMMU and there is no IOMMU visible in the guest. > >>>>>>> > >>>>>>>This patch begins to relax this model, introducing the notion of a > >>>>>>>VFIOAddressSpace. This represents a logical DMA address space whi= ch > >>>>>>>will > >>>>>>>be visible to one or more VFIO devices by appropriate mapping in t= he > >>>>>>>(host) > >>>>>>>IOMMU. Thus the currently global list of containers becomes local= to > >>>>>>>a VFIOAddressSpace, and we verify that we don't attempt to add a V= FIO > >>>>>>>group to multiple address spaces. > >>>>>>> > >>>>>>>For now, only one VFIOAddressSpace is created and used, correspond= ing to > >>>>>>>main system memory, that will change in future patches. > >>>>>>> > >>>>>>>Signed-off-by: David Gibson > >>>>>>>Signed-off-by: Alexey Kardashevskiy > >>>>>>Don't we already have a DMA address space in the PCI bus? We could > >>>>>>just use > >>>>>>that one instead, no? > >>>>>I do not know about x86, but for spapr that VFIOAddressSpace is noth= ing > >>>>>but > >>>>>wrapper around an AddressSpace from the SPAPR PHB. > >>>>So why do we need that wrapper? Can't we just use the PHB's AddressSp= ace? > >>>>There's a good chance I'm not grasping something here :). > >>>We cannot attach VFIO containers (aka "groups" or "PEs" for spapr) to > >>>AddressSpace, there is nothing like that in AddressSpace/MemoryRegion = API > >>>as this container thing is local to VFIO. > >>Ok, please explain how this AddressSpace is different from the VFIO > >>device's parent's IOMMU DMA AddressSpace and why we need it. > >Nothing special. We attach group to address space by trying to add a gro= up > >to every container in that address space. If it fails, we create a new > >container, put new group into it and attach container to the VFIO address > >space. The point here is we attach group to address space. > > > >We could still have a global containers list and when adding a group, lo= op > >through the global list of containers and look at the AS they are attach= ed > >to but the logical structure AS->container->group->device remains the sa= me. >=20 > I honestly still have no idea what all of this is doing and why we can't > model it with PCI buses' IOMMU ASs. Alex, do you grasp it? It's a while since I looked at this, so I may be forgetting. But, I think it's simply a place to store the VFIO-specific per-address-space information. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJTgfHrAAoJEGw4ysog2bOSI/0QALdqu0bQDeq3UoZX9pU4WK6H u0X8AvDOO5k/CSb8S+SwVcftszSfsXnzUf7xrmziQszoi8X9opokRgTeevvNVLcr B739hwHTpdK7s2njQkI10r0KUvx6gtz3U+Vv0sxcJ3Rtdu2RlTeqqR2IvAN2Fvyx m1jSsBsn7MhcXDpidyITyS7NhKe5mc2/6G/BNNSbS6g1w9mriqxy73ruL/Cb6F9J jMV33Xm2yljYGCJaldU6AoSjJsOfn8hI+TM2ysONnuGFStjWSSclqAE6Sk8jkDJL ZGI6nFzPXGvgFs4+mV3t1h1RDg9uhcGcVUuEzqHVUV0H0aGJPwXSAUE8RC+UcT5K qcb2qEYzT/J1pxVdEkUHCmrUvDN+1meTvZvU6ir4uLMVwtkG6iPkUfYHibiHFSFc MG1pWZ+aPZ6pM8MSKgcuOtL1YfYod2Mo3ZKEEiBcY0gwuiFvOrzZx4Y/srhxC4YP NKSiJopJ03/2UTWOLMglLeWTe9JThXtGs9dXwVaqU82U08vPMnp/HqPsC8pDqemL RnwbcmTbfX3oMx7G39wBsIq7Tlhf2tOUjpqXBWpqcv8QoeJbN3mKJLDJ6ecGNagt z1kFGgrosWCzgALhFFtyZI00ruuoTOKvdpjxrv4lIiKpd6J8XYLo1nC8qn6lEBSD WJXCf3NJGRQNxqhPWTxv =4dui -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx--