From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC PATCH 2/3] arch, arm32: add the XEN_DOMCTL_memory_mapping hypercall Date: Mon, 3 Mar 2014 12:56:29 +0100 Message-ID: <1393847789.4058.62.camel@Solace> References: <1393721365-22458-1-git-send-email-avanzini.arianna@gmail.com> <1393721365-22458-3-git-send-email-avanzini.arianna@gmail.com> <53130053.9050801@linaro.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1842018285472681061==" Return-path: In-Reply-To: <53130053.9050801@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: paolo.valente@unimore.it, Ian Campbell , stefano.stabellini@eu.citrix.com, Tim Deegan , xen-devel@lists.xen.org, julien.grall@citrix.com, etrudeau@broadcom.com, Arianna Avanzini , viktor.kleinik@globallogic.com List-Id: xen-devel@lists.xenproject.org --===============1842018285472681061== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-V+zV/E2e6dx6MUrOFoHF" --=-V+zV/E2e6dx6MUrOFoHF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On dom, 2014-03-02 at 17:56 +0800, Julien Grall wrote: > On 02/03/14 08:49, Arianna Avanzini wrote: > > + > > + ret =3D -EPERM; > > + /* > > + * NOTE: dom0 seems to have empty iomem_caps but to be however able t= o > > + * access I/O memory ranges. The following check takes for gran= ted > > + * that any iomem range can be mapped to a domU if the current > > + * domain is dom0. > > + */ > > + if ( current->domain->domain_id !=3D 0 && > > + !iomem_access_permitted(current->domain, mfn, mfn + nr_mf= ns - 1) ) > > + return ret; >=20 > This check can be removed by adding in construct_dom0=20 > (arch/arm/domain_build.c) something like that: > /* DOM0 is permitted full I/O capabilities */ > rc =3D iomem_permit_access(d, 0UL, ~OUL); >=20 Right. FTR, xen/arch/x86/domain_build.c, has this (also in construct_dom0): /* DOM0 is permitted full I/O capabilities. */ rc |=3D ioports_permit_access(dom0, 0, 0xFFFF); rc |=3D iomem_permit_access(dom0, 0UL, ~0UL); rc |=3D irqs_permit_access(dom0, 1, nr_irqs_gsi - 1); Do you want a patch to that/similar effect? > I'm wondering if we can even restrict dom0 I/0 access by only permit=20 > access on devices passthrough to it. Because dom0 should not be allowed= =20 > to map I/O ranges which belong to device used by Xen e.g : GIC, RAM,... >=20 So, this is probably me messing up with the terminology, but what 'devices passthrough to it [dom0]' would mean, for example in cases where we don't have an IOMMU (like cubie* boards), and hence where proper passtrhogh will never be, I think, supported? Or do we plan to have it working there too? Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-V+zV/E2e6dx6MUrOFoHF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEABECAAYFAlMUbe0ACgkQk4XaBE3IOsSSwACfSWVjxAeWgO8THair0qSDqPgH aPAAnR5lTISADdTGM2/EmYD4mA3nBx9V =lAMb -----END PGP SIGNATURE----- --=-V+zV/E2e6dx6MUrOFoHF-- --===============1842018285472681061== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============1842018285472681061==--