From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [RFC PATCH 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall Date: Mon, 3 Mar 2014 11:32:16 +0100 Message-ID: <1393842736.4058.20.camel@Solace> References: <1393721365-22458-1-git-send-email-avanzini.arianna@gmail.com> <1393721365-22458-4-git-send-email-avanzini.arianna@gmail.com> <531308FD.8070007@linaro.org> <1393759633.19684.39.camel@hastur.hellion.org.uk> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3825029485531584218==" Return-path: In-Reply-To: <1393759633.19684.39.camel@hastur.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: paolo.valente@unimore.it, stefano.stabellini@eu.citrix.com, Julien Grall , Ian Jackson , 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 --===============3825029485531584218== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cbPg0U4lizUuT4IWEZ4Y" --=-cbPg0U4lizUuT4IWEZ4Y Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On dom, 2014-03-02 at 11:27 +0000, Ian Campbell wrote: > On Sun, 2014-03-02 at 18:33 +0800, Julien Grall wrote: > > Do you plan to give I/O mem range which is not describe by the device t= ree? > >=20 > > IHMO, allow the user to specify which I/O mem region will be mapped to= =20 > > the guest on ARM is wrong. As the platform is described via the device= =20 > > tree, the guest configuration should have a list of node to map to domU= .=20 > > Then {lib,}xl will parse/map/update the DT node to the guest. >=20 > I think there is room for both models. People just doing basic device > pass-through will probably want a "user friendly" DT based option, but > others might want to use a lower level raw interface, just like on x86 > where we provide both the low level iomem/ioport/irq interface and the > pci passthrough syntax. >=20 That indeed is the case. The automotive OS Arianna is porting on Xen on ARM doesn't know anything about device trees. Actually, a DT parser would probably be more code than the OS itself! :-P AFAIUI, that's Eric's case too. In fact this is, I think, quite common in small/embedded OSes, and it would be a good thing for Xen to allow them to work as guests, without necessarily requiring them to go for DT (of course, the cost of keeping things consistent is on them!). > If they want to hard code an address in both their cfg file and their > guest kernel then that is up to them, they get to keep both pieces when > we changes things of course. >=20 Right. So, just to make sure I understand it correctly, you're saying that it is fine to have the hypercall implemented and called sort of like how Arianna is doing it, modulo moving the call outside of common ARM and x86 code, as Julien pointed out, is this correct? If yes, I (FWIW) totally concur. :-) For the sake of this series, do you think there is something that Arianna should do, if not to ensure 100% consistency (which is not Xen's job, in this case) but, perhaps, just to put things on the safe side? > We might need some sort of ARM equivalent to the x86 "e820_host" option > -- which makes the guest address space look like the hosts (similar to > what we do for dom0 on ARM). >=20 Right. Again, and sorry for not getting it just from the above, do you think this is something Arianna should take care of, when reposting the series, or can/should it be done also later? Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-cbPg0U4lizUuT4IWEZ4Y 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) iEYEABECAAYFAlMUWjEACgkQk4XaBE3IOsTl/wCgnYv9nBqwD0tMLYCuzd7YYh8C sBgAnRhpnbYHamIetZ2uRUY2pDteUfAN =xFjQ -----END PGP SIGNATURE----- --=-cbPg0U4lizUuT4IWEZ4Y-- --===============3825029485531584218== 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 --===============3825029485531584218==--