Re: [RFC PATCH 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2691 bytes --]

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 tree?
> > 
> > IHMO, allow the user to specify which I/O mem region will be mapped to 
> > the guest on ARM is wrong. As the platform is described via the device 
> > tree, the guest configuration should have a list of node to map to domU. 
> > Then {lib,}xl will parse/map/update the DT node to the guest.
> 
> 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.
> 
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.
> 
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).
> 
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

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel