From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC PATCH v2 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall Date: Thu, 13 Mar 2014 17:36:38 +0100 Message-ID: <1394728598.4159.47.camel@Solace> References: <1394439953-5723-1-git-send-email-avanzini.arianna@gmail.com> <1394439953-5723-4-git-send-email-avanzini.arianna@gmail.com> <1394724477.25873.105.camel@kazak.uk.xensource.com> <5321D005.8020203@linaro.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0988644323544216823==" Return-path: In-Reply-To: <5321D005.8020203@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, Keir Fraser , Ian Campbell , stefano.stabellini@eu.citrix.com, Ian.Jackson@eu.citrix.com, Tim Deegan , xen-devel@lists.xen.org, julien.grall@citrix.com, etrudeau@broadcom.com, Jan Beulich , Arianna Avanzini , viktor.kleinik@globallogic.com List-Id: xen-devel@lists.xenproject.org --===============0988644323544216823== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WrpitvM4qLHnMByXim0U" --=-WrpitvM4qLHnMByXim0U Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On gio, 2014-03-13 at 15:34 +0000, Julien Grall wrote: > >> diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c > >> index a604cd8..6c206c3 100644 > >> --- a/tools/libxl/libxl_create.c > >> +++ b/tools/libxl/libxl_create.c > >> @@ -1099,6 +1099,23 @@ static void domcreate_launch_dm(libxl__egc *egc= , libxl__multidev *multidev, > >> + } else { > >> + /* > >> + * NOTE: the following code is still common to both x86 > >> + * and ARM; it also implements a simple 1:1 mapping > >> + * that could clash with the domU's existing memory > >> + * layout if the range is already in use in the > >> + * guest's address space. > >=20 > > The right thing to do here is to add a guest address field to > > libxl_iomem_range and to extend the xl parse to accept > > iomem =3D [ "MFN,NR@PFN" ] syntax > > where @PFN is optional and the default is 1:1. >=20 > I disagree with this solution, the user doesn't know the guest layout. > How is it possible to let him choose the pfn? >=20 I agree that the user will very much likely not know the guest layout. Still, making @PFN optional and defaulting to 1:1, as Ian was suggesting, seems the more flexible solution possible, as it does the right thing (in combination with "layout passthrough", of course, as you say below), but provide enough flexibility for some strange use case we can't predict yet. What's the downside of that? > I think, for now the best solution is to expose the same memory layout > as the host when iomem is set. >=20 Sure, but I don't think I see any conflict between this and the approach Ian proposed above. What am I missing? Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-WrpitvM4qLHnMByXim0U 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) iEYEABECAAYFAlMh3pYACgkQk4XaBE3IOsTYsgCeLlv+nWT4O14n11Oq2sGnxM74 PXwAmgPCUIDegXBYZY671w6yCLwYSTT5 =nCBq -----END PGP SIGNATURE----- --=-WrpitvM4qLHnMByXim0U-- --===============0988644323544216823== 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 --===============0988644323544216823==--