Re: [Xen-devel] [PATCH 1/4] hvm: NUMA guest: extend memops hypercall

[Andre Przywara <andre.przywara@xxxxxxx>]

Keir Fraser wrote:
> On 4/7/08 13:48, "Andre Przywara" <andre.przywara@xxxxxxx> wrote:
>
> > > Looking some more, I still don't see that this patch can work. Don't the
> > > subfunctions in memory.c go and OR in MEMF_node() values on top of what the
> > > caller may have specified??
> > Maybe I don't get your question right, but the only part where the
> > caller specified node number is used is the line I handled in the last
> > patch. Later they only use the member memflags of struct memop_args, not
> > struct xen_memory_reservation. If the node number is not specified (or
> > blocked), it will be later determined by looking at the current
> > scheduled pCPU (and thus node), but this is the current behavior anyway.
> Take common/memory.c:populate_physmap() as a specific example. It
> unconditionally specifies MEMF_node() in its invocation of
> alloc_domheap_pages(), regardless of whether its caller has already
> specified a node in the memop_args structure that is passed into it.
Have you applied the patches correctly? From 02_numa_guest.patch:
@@ -115,7 +113,7 @@
             goto out;

         page = alloc_domheap_pages(
-            d, a->extent_order, a->memflags | MEMF_node(node));
+            d, a->extent_order, a->memflags);
         if ( unlikely(page == NULL) )
         {
             gdprintk(XENLOG_INFO, "Could not allocate order=%d extent:"

The other use of MEMF_node is in exchange_memory, which is not given any 
NUMA node info from the caller, so this is correct.
Regards,
Andre.

--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
----to satisfy European Law for business letters:
AMD Saxony Limited Liability Company & Co. KG,
Wilschdorfer Landstr. 101, 01109 Dresden, Germany
Register Court Dresden: HRA 4896, General Partner authorized
to represent: AMD Saxony LLC (Wilmington, Delaware, US)
General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel