From: Julien Grall <julien.grall@linaro.org>
To: Arianna Avanzini <avanzini.arianna@gmail.com>, xen-devel@lists.xen.org
Cc: paolo.valente@unimore.it, Ian Campbell <Ian.Campbell@citrix.com>,
stefano.stabellini@eu.citrix.com, dario.faggioli@citrix.com,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
julien.grall@citrix.com, etrudeau@broadcom.com,
viktor.kleinik@globallogic.com
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 [thread overview]
Message-ID: <531308FD.8070007@linaro.org> (raw)
In-Reply-To: <1393721365-22458-4-git-send-email-avanzini.arianna@gmail.com>
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 <avanzini.arianna@gmail.com>
> Cc: Dario Faggioli <dario.faggioli@citrix.com>
> Cc: Paolo Valente <paolo.valente@unimore.it>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Julien Grall <julien.grall@citrix.com>
> Cc: Eric Trudeau <etrudeau@broadcom.com>
> Cc: Viktor Kleinik <viktor.kleinik@globallogic.com>
> ---
> 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
next prev parent reply other threads:[~2014-03-02 10:33 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-02 0:49 [RFC PATCH 0/3] Implement the XEN_DOMCTL_memory_mapping hypecall for arm32 Arianna Avanzini
2014-03-02 0:49 ` [RFC PATCH 1/3] arch, arm32: add definition of paddr_bits Arianna Avanzini
2014-03-02 8:13 ` Julien Grall
2014-03-07 0:36 ` Arianna Avanzini
2014-03-02 0:49 ` [RFC PATCH 2/3] arch, arm32: add the XEN_DOMCTL_memory_mapping hypercall Arianna Avanzini
2014-03-02 9:56 ` Julien Grall
2014-03-03 11:56 ` Dario Faggioli
2014-03-03 15:20 ` Julien Grall
2014-03-03 15:33 ` Dario Faggioli
2014-03-04 2:42 ` Julien Grall
2014-03-07 0:47 ` Arianna Avanzini
2014-03-03 16:25 ` Eric Trudeau
2014-03-03 16:35 ` Dario Faggioli
2014-03-03 19:04 ` Eric Trudeau
2014-03-05 13:59 ` Arianna Avanzini
2014-03-06 3:41 ` Julien Grall
2014-03-07 0:57 ` Arianna Avanzini
2014-03-03 18:06 ` Eric Trudeau
2014-03-04 3:08 ` Julien Grall
2014-03-07 0:56 ` Arianna Avanzini
2014-03-07 3:41 ` Julien Grall
2014-03-07 19:49 ` Arianna Avanzini
2014-03-02 0:49 ` [RFC PATCH 3/3] tools, libxl: handle the iomem parameter with the memory_mapping hcall Arianna Avanzini
2014-03-02 10:33 ` Julien Grall [this message]
2014-03-02 11:27 ` Ian Campbell
2014-03-03 10:32 ` Dario Faggioli
2014-03-03 15:13 ` Julien Grall
2014-03-07 0:45 ` Arianna Avanzini
2014-03-07 4:03 ` Julien Grall
2014-03-07 19:54 ` Arianna Avanzini
2014-03-03 11:19 ` Dario Faggioli
2014-03-07 4:05 ` Julien Grall
2014-03-02 8:13 ` [RFC PATCH 0/3] Implement the XEN_DOMCTL_memory_mapping hypecall for arm32 Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=531308FD.8070007@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=avanzini.arianna@gmail.com \
--cc=dario.faggioli@citrix.com \
--cc=etrudeau@broadcom.com \
--cc=julien.grall@citrix.com \
--cc=paolo.valente@unimore.it \
--cc=stefano.stabellini@eu.citrix.com \
--cc=viktor.kleinik@globallogic.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).