All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Cc: Juergen Gross <jgross@suse.com>, Ian Jackson <ian.jackson@eu.citrix.com>
Subject: Re: [PATCH] libxc: refactor memory allocation functions
Date: Tue, 1 Dec 2015 11:58:44 +0000	[thread overview]
Message-ID: <1448971124.15768.117.camel@citrix.com> (raw)
In-Reply-To: <1448969956-26310-1-git-send-email-wei.liu2@citrix.com>

On Tue, 2015-12-01 at 11:39 +0000, Wei Liu wrote:
> There were some problems with the original memory allocation functions:
> 1. xc_dom_alloc_segment and xc_dom_alloc_pad ended up calling
>    xc_dom_chk_alloc_pages while xc_dom_alloc_page open-coded everything.
> 2. xc_dom_alloc_pad didn't call dom->allocate.
> 
> Refactor the code so that:
> 1. xc_dom_alloc_{segment,pad,page} end up calling
>    xc_dom_chk_alloc_pages.
> 2. xc_dom_chk_alloc_pages calls dom->allocate.
> 
> This way we avoid scattering dom->allocate over multiple locations and
> open-coding.
> 
> Also change the return type of xc_dom_alloc_page to xen_pfn_t and return
> an invalid pfn when xc_dom_chk_alloc_pages fails.

Given this presumably the handful of callers ought to gain some error
handling in a followup patch?

xc_dom_chk_alloc_pages does log, so at least the callers needn't bother
with that.

> Signed-off-by: Wei Liu <wei.liu2@citrix.com>

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> ---
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Juergen Gross <jgross@suse.com>
> 
> We don't have INVALID_PFN, maybe we need one?

We have INVALID_MFN and INVALID_P2M_ENTRY, not sure if the latter fits the
bill (or if not how it is distinct from the former).

> 
> Tested with Jessie with 64 bit pvgrub, Wheezy with 64 bit pvgrub, Wheezy
> pv
> guest, Wheezy HVM guest, Wheezy HVM with qemu stubdom.

Also by me in my previously failing environment =>

Tested-by: Ian Campbell <ian.campbell@citrix.com>

I think there are two more fixes in this space:
    libxc: correct domain builder for 64 bit guest with 32 bit tools
    libxc: use correct return type for do_memory_op()

I intend to pick up all three for commit in a moment, prod me if there are
others.

> 
>  tools/libxc/include/xc_dom.h |  2 +-
>  tools/libxc/xc_dom_core.c    | 16 +++++++---------
>  2 files changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/libxc/include/xc_dom.h b/tools/libxc/include/xc_dom.h
> index 2176216..2d0de8c 100644
> --- a/tools/libxc/include/xc_dom.h
> +++ b/tools/libxc/include/xc_dom.h
> @@ -350,7 +350,7 @@ char *xc_dom_strdup(struct xc_dom_image *dom, const
> char *str);
>  
>  /* --- alloc memory pool ------------------------------------------- */
>  
> -int xc_dom_alloc_page(struct xc_dom_image *dom, char *name);
> +xen_pfn_t xc_dom_alloc_page(struct xc_dom_image *dom, char *name);
>  int xc_dom_alloc_segment(struct xc_dom_image *dom,
>                           struct xc_dom_seg *seg, char *name,
>                           xen_vaddr_t start, xen_vaddr_t size);
> diff --git a/tools/libxc/xc_dom_core.c b/tools/libxc/xc_dom_core.c
> index 5d6c3ba..8967970 100644
> --- a/tools/libxc/xc_dom_core.c
> +++ b/tools/libxc/xc_dom_core.c
> @@ -555,6 +555,9 @@ static int xc_dom_chk_alloc_pages(struct xc_dom_image
> *dom, char *name,
>      dom->pfn_alloc_end += pages;
>      dom->virt_alloc_end += pages * page_size;
>  
> +    if ( dom->allocate )
> +        dom->allocate(dom);
> +
>      return 0;
>  }
>  
> @@ -602,9 +605,6 @@ int xc_dom_alloc_segment(struct xc_dom_image *dom,
>      if ( xc_dom_chk_alloc_pages(dom, name, pages) )
>          return -1;
>  
> -    if (dom->allocate)
> -        dom->allocate(dom);
> -
>      /* map and clear pages */
>      ptr = xc_dom_seg_to_ptr(dom, seg);
>      if ( ptr == NULL )
> @@ -621,18 +621,16 @@ int xc_dom_alloc_segment(struct xc_dom_image *dom,
>      return 0;
>  }
>  
> -int xc_dom_alloc_page(struct xc_dom_image *dom, char *name)
> +xen_pfn_t xc_dom_alloc_page(struct xc_dom_image *dom, char *name)
>  {
> -    unsigned int page_size = XC_DOM_PAGE_SIZE(dom);
>      xen_vaddr_t start;
>      xen_pfn_t pfn;
>  
>      start = dom->virt_alloc_end;
>      pfn = dom->pfn_alloc_end - dom->rambase_pfn;
> -    dom->virt_alloc_end += page_size;
> -    dom->pfn_alloc_end++;
> -    if ( dom->allocate )
> -        dom->allocate(dom);
> +
> +    if ( xc_dom_chk_alloc_pages(dom, name, 1) )
> +        return (xen_pfn_t)-1;
>  
>      DOMPRINTF("%-20s:   %-12s : 0x%" PRIx64 " (pfn 0x%" PRIpfn ")",
>                __FUNCTION__, name, start, pfn);

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  parent reply	other threads:[~2015-12-01 11:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-01 11:39 [PATCH] libxc: refactor memory allocation functions Wei Liu
2015-12-01 11:45 ` Juergen Gross
2015-12-01 12:38   ` Ian Campbell
2015-12-01 11:58 ` Ian Campbell [this message]
2015-12-01 12:03   ` Wei Liu
2015-12-01 12:14     ` Ian Campbell
2015-12-01 12:04   ` Juergen Gross
2015-12-01 12:12     ` Wei Liu
2015-12-01 14:08       ` 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=1448971124.15768.117.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jgross@suse.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.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.