From: Ian Campbell <ian.campbell@citrix.com>
To: Juergen Gross <jgross@suse.com>,
xen-devel@lists.xen.org, ian.jackson@eu.citrix.com,
stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com
Subject: Re: [PATCH v2 3/5] libxc: create unmapped initrd in domain builder if supported
Date: Fri, 2 Oct 2015 13:59:39 +0100 [thread overview]
Message-ID: <1443790779.11707.95.camel@citrix.com> (raw)
In-Reply-To: <1443764987-23639-4-git-send-email-jgross@suse.com>
On Fri, 2015-10-02 at 07:49 +0200, Juergen Gross wrote:
> In case the kernel of a new pv-domU indicates it is supporting an
> unmapped initrd, don't waste precious virtual space for the initrd,
> but allocate only guest physical memory for it.
>
> Signed-off-by: Juergen Gross <jgross@suse.com>
> ---
> tools/libxc/xc_dom_core.c | 22 ++++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index b510bbd..85b531a 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -1019,8 +1019,9 @@ int xc_dom_build_image(struct xc_dom_image *dom)
> if ( dom->kernel_loader->loader(dom) != 0 )
> goto err;
>
> - /* load ramdisk */
> - if ( dom->ramdisk_blob )
> + /* Load ramdisk if initial mapping required. */
> + if ( dom->ramdisk_blob &&
> + (!dom->parms.mod_start_pfn || dom->ramdisk_seg.vstart) )
> {
> if ( xc_dom_build_ramdisk(dom) != 0 )
> goto err;
> @@ -1063,6 +1064,23 @@ int xc_dom_build_image(struct xc_dom_image *dom)
> __FUNCTION__, dom->virt_alloc_end);
> DOMPRINTF("%-20s: virt_pgtab_end : 0x%" PRIx64 "",
> __FUNCTION__, dom->virt_pgtab_end);
> +
> + /* Prepare allocating unmapped memory. */
> + if ( dom->virt_pgtab_end )
> + dom->virt_alloc_end = dom->virt_pgtab_end;
> +
> + /* Load ramdisk if no initial mapping required. */
> + if ( dom->ramdisk_blob && !dom->ramdisk_seg.vstart &&
> + dom->parms.mod_start_pfn )
> + {
> + if ( xc_dom_build_ramdisk(dom) != 0 )
> + goto err;
> + dom->flags |= SIF_MOD_START_PFN;
> + dom->ramdisk_seg.vend = dom->ramdisk_seg.vend - dom->ramdisk_seg.vstart;
> + dom->ramdisk_seg.vstart = dom->ramdisk_seg.pfn;
> + dom->ramdisk_seg.vend += dom->ramdisk_seg.vstart;
This seems like it is trying to do something clever, like partially
reversing something which the xc_dom_alloc_segment call in
xc_dom_build_ramdisk has done.
It looks like the vend handling in particular is just a complicated way of
subtracting vstart and adding pfn, with the aim of rebasing from virt to
phys world.
Plus vstart/end are addresses, while presumably pfn is a page number, so
I'm confused about that as well.
I'm also not clear how/where the virtual mapping is avoided, given that
this code here does strictly more than the original code above which is now
made conditional does.
Ian.
next prev parent reply other threads:[~2015-10-02 12:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-02 5:49 [PATCH v2 0/5] libxc: support building large pv-domains Juergen Gross
2015-10-02 5:49 ` [PATCH v2 1/5] libxc: remove allocate member from struct xc_dom_image Juergen Gross
2015-10-02 13:01 ` Ian Campbell
2015-10-02 14:25 ` Juergen Gross
2015-10-02 14:47 ` Ian Campbell
2015-10-02 15:00 ` Juergen Gross
2015-10-02 5:49 ` [PATCH v2 2/5] xen: add generic flag to elf_dom_parms indicating support of unmapped initrd Juergen Gross
2015-10-02 9:37 ` Andrew Cooper
2015-10-02 9:41 ` Jan Beulich
2015-10-02 9:44 ` Juergen Gross
2015-10-02 9:53 ` Andrew Cooper
2015-10-02 10:01 ` Juergen Gross
2015-10-02 10:22 ` Ian Campbell
2015-10-02 5:49 ` [PATCH v2 3/5] libxc: create unmapped initrd in domain builder if supported Juergen Gross
2015-10-02 12:59 ` Ian Campbell [this message]
2015-10-02 14:46 ` Juergen Gross
2015-10-02 14:56 ` Ian Campbell
2015-10-02 15:13 ` Juergen Gross
2015-10-02 15:21 ` Ian Campbell
2015-10-02 16:28 ` Juergen Gross
2015-10-02 5:49 ` [PATCH v2 4/5] libxc: split p2m allocation in domain builder from other magic pages Juergen Gross
2015-10-02 9:29 ` Ian Campbell
2015-10-02 5:49 ` [PATCH v2 5/5] libxc: create p2m list outside of kernel mapping if supported Juergen Gross
2015-10-02 13:16 ` Ian Campbell
2015-10-02 14:37 ` Juergen Gross
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=1443790779.11707.95.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=jgross@suse.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.