All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Wei Liu <wei.liu2@citrix.com>
Cc: ufimtseva@gmail.com, andrew.cooper3@citrix.com,
	dario.faggioli@citrix.com, ian.jackson@eu.citrix.com,
	xen-devel@lists.xen.org, JBeulich@suse.com
Subject: Re: [PATCH v4 08/21] libxl: functions to build vmemranges for PV guest
Date: Wed, 28 Jan 2015 16:27:29 +0000	[thread overview]
Message-ID: <1422462449.5187.50.camel@citrix.com> (raw)
In-Reply-To: <1422011632-22018-9-git-send-email-wei.liu2@citrix.com>

On Fri, 2015-01-23 at 11:13 +0000, Wei Liu wrote:
> +    /* Generate one vmemrange for each virtual node. */
> +    next = 0;
> +    for (i = 0; i < b_info->num_vnuma_nodes; i++) {
> +        libxl_vnode_info *p = &b_info->vnuma_nodes[i];
> +
> +        GCREALLOC_ARRAY(v, i+1);

Can we not just allocate it outside the loop using
b_info->num_vnuma_nodes?

> +
> +        v[i].start = next;
> +        v[i].end = next + (p->memkb << 10);
> +        v[i].flags = 0;
> +        v[i].nid = i;
> +
> +        next = v[i].end;
> +    }
> +
> +    state->vmemranges = v;
> +    state->num_vmemranges = i;
> +
> +    return libxl__arch_vnuma_build_vmemrange(gc, domid, b_info, state);
> +}
> +
>  /*
>   * Local variables:
>   * mode: C
> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
> index d012b4d..4841fef 100644
> --- a/tools/libxl/libxl_x86.c
> +++ b/tools/libxl/libxl_x86.c
> @@ -339,6 +339,82 @@ int libxl__arch_domain_finalise_hw_description(libxl__gc *gc,
>      return 0;
>  }
>  
> +int libxl__arch_vnuma_build_vmemrange(libxl__gc *gc,

This isn't so much "build" as "adjust" or "make it fit arch policy" or
something?

> +                                      uint32_t domid,
> +                                      libxl_domain_build_info *b_info,
> +                                      libxl__domain_build_state *state)
> +{
> +    int nid, nr_vmemrange, rc;
> +    uint32_t nr_e820, e820_count;
> +    struct e820entry map[E820MAX];
> +    xen_vmemrange_t *vmemranges;
> +
> +    /* Only touch vmemranges if it's PV guest and e820_host is true */

I take it that obeying e820_host here is only WRT where the memory is
placed, not also trying to match the underlying hosts numa layout?

> +    if (!(b_info->type == LIBXL_DOMAIN_TYPE_PV &&
> +          libxl_defbool_val(b_info->u.pv.e820_host))) {
> +        rc = 0;
> +        goto out;
> +    }
> +
> +    rc = e820_host_sanitize(gc, b_info, map, &nr_e820);
> +    if (rc) goto out;
> +
> +    /* Ditch old vmemranges and start with host E820 map. Note, memory
> +     * was gc allocated.

This makes me thing something is backwards in the layering here.

Wouldn't it make more sense for libxl__arch_vnuma_build_vmemrange to be
the entry point which starts with:
    if (nothing unusual like e820_host going on)
        return libxl__vnuma_build_pv_generic(...)

    ...the special stuff.

> +    e820_count = 0;
> +    nr_vmemrange = 0;
> +    vmemranges = NULL;
> +    for (nid = 0; nid < b_info->num_vnuma_nodes; nid++) {

This fill-loop looked ok to me.

  reply	other threads:[~2015-01-28 16:27 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-23 11:13 [PATCH v4 00/21] Virtual NUMA for PV and HVM Wei Liu
2015-01-23 11:13 ` [PATCH v4 01/21] xen: dump vNUMA information with debug key "u" Wei Liu
2015-01-23 13:03   ` Jan Beulich
2015-01-23 13:23     ` Wei Liu
2015-01-23 11:13 ` [PATCH v4 02/21] xen: make two memory hypercalls vNUMA-aware Wei Liu
2015-01-23 13:16   ` Jan Beulich
2015-01-23 14:46     ` Wei Liu
2015-01-23 15:37       ` Jan Beulich
2015-01-23 15:43         ` Wei Liu
2015-01-23 16:06           ` Wei Liu
2015-01-23 16:17             ` Jan Beulich
2015-01-23 11:13 ` [PATCH v4 03/21] libxc: allocate memory with vNUMA information for PV guest Wei Liu
2015-01-28 16:02   ` Ian Campbell
2015-01-23 11:13 ` [PATCH v4 04/21] libxl: introduce vNUMA types Wei Liu
2015-01-28 16:04   ` Ian Campbell
2015-01-28 21:51     ` Wei Liu
2015-01-23 11:13 ` [PATCH v4 05/21] libxl: add vmemrange to libxl__domain_build_state Wei Liu
2015-01-28 16:05   ` Ian Campbell
2015-01-23 11:13 ` [PATCH v4 06/21] libxl: introduce libxl__vnuma_config_check Wei Liu
2015-01-28 16:13   ` Ian Campbell
2015-01-28 21:51     ` Wei Liu
2015-01-29 11:04       ` Ian Campbell
2015-01-29 16:01         ` Wei Liu
2015-01-23 11:13 ` [PATCH v4 07/21] libxl: x86: factor out e820_host_sanitize Wei Liu
2015-01-28 16:14   ` Ian Campbell
2015-01-23 11:13 ` [PATCH v4 08/21] libxl: functions to build vmemranges for PV guest Wei Liu
2015-01-28 16:27   ` Ian Campbell [this message]
2015-01-28 21:59     ` Wei Liu
2015-01-23 11:13 ` [PATCH v4 09/21] libxl: build, check and pass vNUMA info to Xen " Wei Liu
2015-01-28 16:29   ` Ian Campbell
2015-01-23 11:13 ` [PATCH v4 10/21] xen: handle XENMEM_get_vnumainfo in compat_memory_op Wei Liu
2015-01-23 11:13 ` [PATCH v4 11/21] hvmloader: retrieve vNUMA information from hypervisor Wei Liu
2015-01-23 13:27   ` Jan Beulich
2015-01-23 14:17     ` Wei Liu
2015-01-23 11:13 ` [PATCH v4 12/21] hvmloader: construct SRAT Wei Liu
2015-01-23 11:13 ` [PATCH v4 13/21] hvmloader: construct SLIT Wei Liu
2015-01-23 11:13 ` [PATCH v4 14/21] libxc: indentation change to xc_hvm_build_x86.c Wei Liu
2015-01-28 16:30   ` Ian Campbell
2015-01-23 11:13 ` [PATCH v4 15/21] libxc: allocate memory with vNUMA information for HVM guest Wei Liu
2015-01-28 16:36   ` Ian Campbell
2015-01-28 22:07     ` Wei Liu
2015-01-23 11:13 ` [PATCH v4 16/21] libxl: build, check and pass vNUMA info to Xen " Wei Liu
2015-01-28 16:41   ` Ian Campbell
2015-01-28 22:14     ` Wei Liu
2015-01-23 11:13 ` [PATCH v4 17/21] libxl: disallow memory relocation when vNUMA is enabled Wei Liu
2015-01-28 16:41   ` Ian Campbell
2015-01-28 22:22     ` Wei Liu
2015-01-29 11:06       ` Ian Campbell
2015-01-29 16:04         ` Wei Liu
2015-01-23 11:13 ` [PATCH v4 18/21] libxlu: rework internal representation of setting Wei Liu
2015-01-28 16:41   ` Ian Campbell
2015-02-11 16:12   ` Ian Jackson
2015-02-12 10:58     ` Wei Liu
2015-01-23 11:13 ` [PATCH v4 19/21] libxlu: nested list support Wei Liu
2015-02-11 16:13   ` Ian Jackson
2015-01-23 11:13 ` [PATCH v4 20/21] libxlu: introduce new APIs Wei Liu
2015-02-11 16:17   ` Ian Jackson
2015-02-12 10:57     ` Wei Liu
2015-01-23 11:13 ` [PATCH v4 21/21] xl: vNUMA support Wei Liu
2015-01-28 16:46   ` Ian Campbell
2015-01-28 22:52     ` Wei Liu
2015-01-29 11:10       ` Ian Campbell
2015-01-29 17:46         ` Wei Liu
2015-02-24 16:15           ` Dario Faggioli

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=1422462449.5187.50.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dario.faggioli@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=ufimtseva@gmail.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.