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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Sun, 2014-03-02 at 18:33 +0800, Julien Grall wrote:
> Hello Arianna,
> 
> Adding Ian Jackson, maintainer of libxl.
> 
> On 02/03/14 08:49, Arianna Avanzini wrote:
> > Currently, the configuration-parsing code concerning the handling of the
> > iomem parameter only invokes the XEN_DOMCTL_iomem_permission hypercall.
> > This commit lets the XEN_DOMCTL_memory_mapping hypercall be invoked
> > after XEN_DOMCTL_iomem_permission when the iomem parameter is parsed
> > from a domU configuration file.
> 
> 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.

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.

> The 1:1 mapping doesn't seem correct because the range could clash with 
> the guest layout (e.g: GIC base address, RAM base address) which is for 
> now hardcoded (see xen/include/public/arch-arm.h:358).
> 
> I have various solution to fix this issue:
>    - Relocate the GIC/RAM base address and notify Xen that the GIC base 
> address has changed. So we can keep the 1:1 mapping.
>    - Let libxl decide where to map the I/O mem range in the guest.

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).

> For the latter solution, we will have to find a way to tell to the guest 
> : "This I/O mem range is here ...". Perhaps via the device tree.
> 
> Regards,
> 



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