[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 08/21] libxl: functions to build vmemranges for PV guest
On Wed, Jan 28, 2015 at 04:27:29PM +0000, Ian Campbell wrote: > 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? > Yes. > > + > > + 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? > "adjust" is better. > > + 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? > It's used to set aside memory holes according to host e820 map. It doesn't take into account host 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. > OK. That's fine by me. Wei. > > + 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. > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |