From: Julien Grall <julien.grall@linaro.org>
To: Arianna Avanzini <avanzini.arianna@gmail.com>
Cc: julien.grall@citrix.com, paolo.valente@unimore.it, keir@xen.org,
stefano.stabellini@eu.citrix.com, tim@xen.org,
dario.faggioli@citrix.com, Ian.Jackson@eu.citrix.com,
xen-devel@lists.xen.org, Ian.Campbell@eu.citrix.com,
etrudeau@broadcom.com, JBeulich@suse.com,
viktor.kleinik@globallogic.com
Subject: Re: [PATCH v4 5/7] tools, libxl: parse optional start gfn from the iomem config option
Date: Tue, 25 Mar 2014 15:39:48 +0000 [thread overview]
Message-ID: <5331A344.9000801@linaro.org> (raw)
In-Reply-To: <1395712976-19454-6-git-send-email-avanzini.arianna@gmail.com>
Hi Arianna,
Thank you for the patch.
On 03/25/2014 02:02 AM, Arianna Avanzini wrote:
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index 06bbca6..13f5fe7 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -95,6 +95,16 @@
> #define LIBXL_HAVE_BUILDINFO_EVENT_CHANNELS 1
>
> /*
> + * LIBXL_HAVE_BUILDINFO_IOMEM_START_GFN indicated that it is possible
> + * to specify the start guest frame number used to map a range of I/O
> + * memory machine frame numbers via the 'gfn' field (of type uint64)
> + * of the 'iomem' structure. An array of iomem structures is embedded
> + * in libxl_domain_build_info and used to map the indicated memory
> + * ranges during domain build.
> + */
> +#define LIBXL_HAVE_BUILDINFO_IOMEM_START_GFN 1
> +
> +/*
> * libxl ABI compatibility
> *
> * The only guarantee which libxl makes regarding ABI compatibility
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 649ce50..4462586 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -169,8 +169,9 @@ libxl_ioport_range = Struct("ioport_range", [
> ])
>
> libxl_iomem_range = Struct("iomem_range", [
> - ("start", uint64),
> - ("number", uint64),
> + ("start", uint64), # start host frame number to be mapped to the guest
> + ("number", uint64), # number of frames to be mapped
> + ("gfn", uint64), # guest frame number used as a start for the mapping
> ])
When this structure will be used by another toolstack (e.g not xl), the
default value for gfn will be 0. This is wrong because we won't be able
to differentiate a user that will want to map to the GFN 0 and a 1:1
mapping. -1 seems the best default value for now.
You can use init_val in the IDL to set this value.
> libxl_vga_interface_info = Struct("vga_interface_info", [
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index 4fc46eb..99a0958 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -1208,13 +1208,20 @@ static void parse_config_data(const char *config_source,
> "xl: Unable to get element %d in iomem list\n", i);
> exit(1);
> }
It's a bug on the current code. We have to init correctly iomem before
with libxl_iomem_range_init(&b_info->iomem);
> - if(sscanf(buf, "%" SCNx64",%" SCNx64,
> - &b_info->iomem[i].start,
> - &b_info->iomem[i].number)
> - != 2) {
> - fprintf(stderr,
> - "xl: Invalid argument parsing iomem: %s\n", buf);
> - exit(1);
> + switch(sscanf(buf, "%" SCNx64",%" SCNx64"@%" SCNx64,
> + &b_info->iomem[i].start,
> + &b_info->iomem[i].number,
> + &b_info->iomem[i].gfn)) {
I don't like the switch(sscanf(... it's hard to read.
I would prefer:
ret = sscanf(...);
switch (ret) {
}
> + case 3: break;
> + case 2:
> + /* default to 1:1 mapping */
> + b_info->iomem[i].gfn = b_info->iomem[i].start;
> + break;
If the iomem_range is initialized with the default value. You can defer
this initialization in libxl.
The result code here will be nicer:
ret = sscanf(...)
if ( ret < 2 )
fprintf(stderr, ...);
Regards,
--
Julien Grall
next prev parent reply other threads:[~2014-03-25 15:39 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-25 2:02 [PATCH v4 0/7] Implement the XEN_DOMCTL_memory_mapping hypercall for ARM Arianna Avanzini
2014-03-25 2:02 ` [PATCH v4 1/7] arch, arm: domain build: let dom0 access I/O memory of mapped devices Arianna Avanzini
2014-03-25 12:37 ` Julien Grall
2014-03-25 2:02 ` [PATCH v4 2/7] arch, arm: add consistency checks to REMOVE p2m changes Arianna Avanzini
2014-03-25 12:18 ` Stefano Stabellini
2014-03-25 12:51 ` Julien Grall
2014-03-25 13:10 ` Julien Grall
2014-03-25 17:41 ` Ian Campbell
2014-03-25 2:02 ` [PATCH v4 3/7] arch, arm: let map_mmio_regions() take pfn as parameters Arianna Avanzini
2014-03-25 12:22 ` Stefano Stabellini
2014-03-25 12:54 ` Julien Grall
2014-03-28 12:51 ` Arianna Avanzini
2014-03-28 13:31 ` Julien Grall
2014-03-25 13:00 ` Julien Grall
2014-03-25 2:02 ` [PATCH v4 4/7] xen, common: add the XEN_DOMCTL_memory_mapping hypercall Arianna Avanzini
2014-03-25 9:33 ` Jan Beulich
2014-03-28 13:24 ` Arianna Avanzini
2014-03-28 13:30 ` Jan Beulich
2014-03-25 12:35 ` Stefano Stabellini
2014-03-25 14:10 ` Jan Beulich
2014-03-25 15:10 ` Stefano Stabellini
2014-03-25 15:36 ` Jan Beulich
2014-03-25 15:42 ` Stefano Stabellini
2014-04-01 15:01 ` Ian Campbell
2014-04-01 15:18 ` Jan Beulich
2014-04-01 15:37 ` Ian Campbell
2014-03-25 13:17 ` Julien Grall
2014-04-01 14:52 ` Ian Campbell
2014-04-01 15:16 ` Julien Grall
2014-04-01 15:39 ` Ian Campbell
2014-04-01 16:00 ` Julien Grall
2014-04-02 9:43 ` Ian Campbell
2014-04-02 10:06 ` Jan Beulich
2014-04-02 10:19 ` Ian Campbell
2014-04-02 10:53 ` Jan Beulich
2014-04-05 12:08 ` Arianna Avanzini
2014-04-06 16:23 ` Stefano Stabellini
2014-04-07 7:01 ` Jan Beulich
2014-03-25 2:02 ` [PATCH v4 5/7] tools, libxl: parse optional start gfn from the iomem config option Arianna Avanzini
2014-03-25 15:39 ` Julien Grall [this message]
2014-03-25 15:45 ` Julien Grall
2014-03-25 16:27 ` Ian Campbell
2014-03-25 2:02 ` [PATCH v4 6/7] tools, libxl: add helpers to establish if guest is auto-translated Arianna Avanzini
2014-03-25 2:02 ` [PATCH v4 7/7] tools, libxl: handle the iomem parameter with the memory_mapping hcall Arianna Avanzini
2014-04-01 15:13 ` Ian Campbell
2014-04-01 15:26 ` Julien Grall
2014-04-01 15:34 ` Ian Campbell
2014-04-01 20:52 ` Daniel De Graaf
2014-04-02 9:45 ` Ian Campbell
2014-04-02 14:14 ` Daniel De Graaf
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=5331A344.9000801@linaro.org \
--to=julien.grall@linaro.org \
--cc=Ian.Campbell@eu.citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=avanzini.arianna@gmail.com \
--cc=dario.faggioli@citrix.com \
--cc=etrudeau@broadcom.com \
--cc=julien.grall@citrix.com \
--cc=keir@xen.org \
--cc=paolo.valente@unimore.it \
--cc=stefano.stabellini@eu.citrix.com \
--cc=tim@xen.org \
--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).