From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48878) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXOoy-00063S-7I for qemu-devel@nongnu.org; Wed, 01 May 2013 00:39:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UXOos-0005DW-2g for qemu-devel@nongnu.org; Wed, 01 May 2013 00:39:12 -0400 Received: from ozlabs.org ([2402:b800:7003:1:1::1]:58498) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UXOor-00058y-MV for qemu-devel@nongnu.org; Wed, 01 May 2013 00:39:06 -0400 Date: Wed, 1 May 2013 14:35:24 +1000 From: David Gibson Message-ID: <20130501043524.GO20202@truffula.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="07UuamFNDT4U/3KT" Content-Disposition: inline Subject: Re: [Qemu-devel] [PATCH 09/17] memory: iommu support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: pbonzini@redhat.com Cc: aik@truffula.fritz.box, qemu-devel@nongnu.org --07UuamFNDT4U/3KT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > From: Avi Kivity >=20 > Add a new memory region type that translates addresses it is given, > then forwards them to a target address space. This is similar to > an alias, except that the mapping is more flexible than a linear > translation and trucation, and also less efficient since the > translation happens at runtime. >=20 > The implementation uses an AddressSpace mapping the target region to > avoid hierarchical dispatch all the way to the resolved region; only > iommu regions are looked up dynamically. >=20 > Signed-off-by: Avi Kivity > [Modified to put translation in address_space_translate - Paolo] > Signed-off-by: Paolo Bonzini > --- > exec.c | 35 +++++++++++++++++++++++++++++------ > include/exec/memory.h | 44 ++++++++++++++++++++++++++++++++++++++++++++ > memory.c | 28 ++++++++++++++++++++++++++++ > 3 files changed, 101 insertions(+), 6 deletions(-) [snip] > +void memory_region_init_iommu(MemoryRegion *mr, > + MemoryRegionIOMMUOps *ops, > + MemoryRegion *target, > + const char *name, > + uint64_t size) > +{ > + memory_region_init(mr, name, size); > + mr->ops =3D NULL; > + mr->iommu_ops =3D ops, > + mr->opaque =3D mr; > + mr->terminates =3D true; /* then re-forwards */ > + mr->destructor =3D memory_region_destructor_iommu; > + mr->iommu_target_as =3D g_new(AddressSpace, 1); > + address_space_init(mr->iommu_target_as, target); Since IOMMUs are very likely to share a target AS (in fact, it will nearly always be system memory), it seems odd to me to construct new AddressSpace objects for each one, rather than just giving the AddressSpace as the parameter to memory_region_init_iommu. --=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 --07UuamFNDT4U/3KT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGAm4wACgkQaILKxv3ab8aIMACfctYcJIIvcl+7ZfFIOJ9Cx+/E J98Anj5o4ES4vqmwN247ckFalPlAFBYn =/BB+ -----END PGP SIGNATURE----- --07UuamFNDT4U/3KT--