[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/2] xen: vnuma support for PV guests running as domU.
On 14/11/13 07:26, Dario Faggioli wrote: > On mer, 2013-11-13 at 22:36 -0500, Elena Ufimtseva wrote: >> + /* >> + * Set the "dummy" node and exit without error so Linux >> + * will not try any NUMA init functions which might break >> + * guests in the future. This will discard all previous >> + * settings. >> + */ > IIRC, it's more something that was already happening (the breakage, I > mean), than a "safety net" for the unforeseeable future. Might be worth > giving some context about it, perhaps referencing the email thread or > the git commit hash in the comment. Yes, a comment like: /* * Set a dummy node and return success. This prevents calling any * hardware-specific initializers which do not work in a PV guest. */ is better. No need to refer to any specific threads. It's pretty clear that any hardware-specific init isn't appropriate for a PV guest. >> + if (rc != 0) { >> + for (i = 0; i < MAX_LOCAL_APIC; i++) >> + set_apicid_to_node(i, NUMA_NO_NODE); >> + nodes_clear(numa_nodes_parsed); >> + nodes_clear(node_possible_map); >> + nodes_clear(node_online_map); >> + node_set(0, numa_nodes_parsed); >> + numa_add_memblk(0, 0, PFN_PHYS(max_pfn)); >> + } >> + return 0; >> > Ok, so, we always return 'success', as we were saying during last round. > However, we do not call dummy_numa_init() directly, and instead we do > all these stuff, with the last two statements being exactly what > dummy_numa_init() does. Reason is linking, i.e., the fact that > dummy_numa_init() is not exported and you can't reach it from here, > right? I think this bit is fine as-is. David _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |