From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC PATCH 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall Date: Sun, 02 Mar 2014 18:33:33 +0800 Message-ID: <531308FD.8070007@linaro.org> References: <1393721365-22458-1-git-send-email-avanzini.arianna@gmail.com> <1393721365-22458-4-git-send-email-avanzini.arianna@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1393721365-22458-4-git-send-email-avanzini.arianna@gmail.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Arianna Avanzini , xen-devel@lists.xen.org Cc: paolo.valente@unimore.it, Ian Campbell , stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com, Ian Jackson , julien.grall@citrix.com, etrudeau@broadcom.com, viktor.kleinik@globallogic.com List-Id: xen-devel@lists.xenproject.org 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. > Signed-off-by: Arianna Avanzini > Cc: Dario Faggioli > Cc: Paolo Valente > Cc: Stefano Stabellini > Cc: Julien Grall > Cc: Eric Trudeau > Cc: Viktor Kleinik > --- > tools/libxl/libxl_create.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c > index a604cd8..7da0778 100644 > --- a/tools/libxl/libxl_create.c > +++ b/tools/libxl/libxl_create.c > @@ -1099,6 +1099,16 @@ static void domcreate_launch_dm(libxl__egc *egc, libxl__multidev *multidev, > "failed give dom%d access to iomem range %"PRIx64"-%"PRIx64, > domid, io->start, io->start + io->number - 1); > ret = ERROR_FAIL; > + } else { > + ret = xc_domain_memory_mapping(CTX->xch, domid, > + io->start, io->start, > + io->number, 1); > + if (ret < 0) { > + LOGE(ERROR, > + "failed to map to dom%d iomem range %"PRIx64"-%"PRIx64, > + domid, io->start, io->start + io->number - 1); > + ret = ERROR_FAIL; > + } This code is common on both x86 and ARM. On x86, we don't want to map the I/O mem region in the guest here. QEMU will do it later. 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. 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, -- Julien Grall