From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com,
ian.campbell@citrix.com, wei.liu2@citrix.com
Cc: jgross@suse.com, xen-devel@lists.xen.org
Subject: Re: [PATCH] libxc: Defer initialization of start_page for HVM guests
Date: Tue, 22 Dec 2015 10:42:03 +0100 [thread overview]
Message-ID: <56791AEB.2080409@citrix.com> (raw)
In-Reply-To: <1450741524-27859-1-git-send-email-boris.ostrovsky@oracle.com>
El 22/12/15 a les 0.45, Boris Ostrovsky ha escrit:
> With commit 8c45adec18e0 ("libxc: create unmapped initrd in domain
> builder if supported") location of ramdisk may not be available to
> HVMlite guests by the time alloc_magic_pages_hvm() is invoked if the
> guest supports unmapped initrd.
>
> Since the only operation related to allocating magic pages in that
> routine is allocation of HVMlite start info we can move everything
> else to a later point such as xc_dom_arch.start_info().
>
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> ---
> I am not sure xc_dom_arch.start_info() is the right place neither since we
> still are doing things that have nothing to do with start_info.
>
> tools/libxc/xc_dom_x86.c | 45 ++++++++++++++++++++++++++++++---------------
> 1 files changed, 30 insertions(+), 15 deletions(-)
>
> diff --git a/tools/libxc/xc_dom_x86.c b/tools/libxc/xc_dom_x86.c
> index 3960875..f64079e 100644
> --- a/tools/libxc/xc_dom_x86.c
> +++ b/tools/libxc/xc_dom_x86.c
> @@ -585,6 +585,32 @@ static void build_hvm_info(void *hvm_info_page, struct xc_dom_image *dom)
>
> static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
> {
> + struct xc_dom_seg seg;
> + size_t start_info_size = sizeof(struct hvm_start_info);
> +
> + if ( dom->device_model )
> + return 0;
> +
> + if ( dom->cmdline )
> + start_info_size += ROUNDUP(strlen(dom->cmdline) + 1, 8);
> + if ( dom->ramdisk_blob )
> + /* Limited to one module. */
> + start_info_size += sizeof( struct hvm_modlist_entry);
^ extra space.
> +
> + if ( xc_dom_alloc_segment(dom, &seg, "HVMlite start info", 0,
> + start_info_size) )
> + {
> + DOMPRINTF("Unable to reserve memory for the start info");
> + return -1;
> + }
> +
> + dom->start_info_pfn = seg.pfn;
> +
> + return 0;
> +}
> +
> +static int start_info_hvm(struct xc_dom_image *dom)
> +{
> unsigned long i;
> void *hvm_info_page;
> uint32_t *ident_pt, domid = dom->guest_domid;
> @@ -636,7 +662,6 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
>
> if ( !dom->device_model )
> {
> - struct xc_dom_seg seg;
> struct hvm_start_info *start_info;
> char *cmdline;
> struct hvm_modlist_entry *modlist;
> @@ -653,17 +678,9 @@ static int alloc_magic_pages_hvm(struct xc_dom_image *dom)
> if ( dom->ramdisk_blob )
> start_info_size += sizeof(*modlist); /* Limited to one module. */
>
> - rc = xc_dom_alloc_segment(dom, &seg, "HVMlite start info", 0,
> - start_info_size);
> - if ( rc != 0 )
> - {
> - DOMPRINTF("Unable to reserve memory for the start info");
> - goto out;
> - }
> -
> start_page = xc_map_foreign_range(xch, domid, start_info_size,
IMHO, I would stash start_info_size somewhere inside xc_dom_image in
order to avoid calculating it twice.
Also, why is everything done inside of alloc_magic_pages_hvm moved to
start_info_hvm? AFAICT we should only need to move the code that fills
the hvm_start_info struct, but the rest of the code already present in
alloc_magic_pages_hvm could be left as-is.
Roger.
next prev parent reply other threads:[~2015-12-22 9:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-21 23:45 [PATCH] libxc: Defer initialization of start_page for HVM guests Boris Ostrovsky
2015-12-22 9:42 ` Roger Pau Monné [this message]
2015-12-22 14:12 ` Boris Ostrovsky
2015-12-22 14:36 ` Roger Pau Monné
2015-12-22 14:48 ` Boris Ostrovsky
2016-01-05 14:06 ` Ian Campbell
2016-01-05 16:37 ` Boris Ostrovsky
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=56791AEB.2080409@citrix.com \
--to=roger.pau@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=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.