[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/4] xen: report how much memory a domain has on each NUMA node
>>> On 05.03.14 at 15:36, Dario Faggioli <dario.faggioli@xxxxxxxxxx> wrote: > --- a/xen/common/domctl.c > +++ b/xen/common/domctl.c > @@ -574,6 +574,51 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) > u_domctl) > } > break; > > + case XEN_DOMCTL_numainfo: > + { > + uint32_t node, max_node_index, last_online_node; > + xen_domctl_numainfo_t *ni = &op->u.numainfo; > + uint64_t *memkb_on_node; > + struct page_info *page; > + > + /* > + * We report back info about the min number of nodes between how > + * much of them the caller can handle and the number of them that > + * are actually online. > + */ > + last_online_node = last_node(node_online_map); > + max_node_index = min_t(uint32_t, ni->max_node_index, > last_online_node); > + ni->max_node_index = max_node_index; > + > + ret = -ENOMEM; > + memkb_on_node = xzalloc_array(uint64_t, max_node_index); max_node_index + 1 > + if ( !memkb_on_node ) > + break; > + > + spin_lock(&d->page_alloc_lock); > + page_list_for_each(page, &d->page_list) No new non-preemptable potentially long running loops like this, please. See XSA-77. > + { > + node = phys_to_nid((paddr_t)page_to_mfn(page) << PAGE_SHIFT); Please don't open-code pfn_to_paddr()/page_to_maddr(). > + /* For nodes that are offline, don't touch the counter */ > + if ( node <= max_node_index && node_online(node) ) How can a node a running domain has memory on be offline? Looks like you want an assertion here instead. > + memkb_on_node[node]++; > + } > + spin_unlock(&d->page_alloc_lock); > + > + for ( node = 0; node <= max_node_index; node++ ) > + { > + memkb_on_node[node] <<= (PAGE_SHIFT-10); > + if ( copy_to_guest_offset(ni->memkb_on_node, node, > + &memkb_on_node[node], 1) ) > + break; I'd suggest to do the copying in one go after the loop. > --- a/xen/include/public/domctl.h > +++ b/xen/include/public/domctl.h > @@ -315,6 +315,26 @@ typedef struct xen_domctl_max_vcpus > xen_domctl_max_vcpus_t; > DEFINE_XEN_GUEST_HANDLE(xen_domctl_max_vcpus_t); > > > +/* XEN_DOMCTL_numainfo */ > +struct xen_domctl_numainfo { > + /* > + * IN: maximum addressable entry in the caller-provided arrays. > + * OUT: minimum between the maximum addressable entry in the > + * caller-provided arrays and largest online node identifier > + * in the system. > + */ > + uint32_t max_node_index; With that IN/OUT specification (and the matching implementation above), how would the caller know it passed too small a value to fit all information? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |