WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [xen-devel][vNUMA v2][PATCH 2/8] public interface

Dulloor wrote:
Interface definition. Structure that will be shared with hvmloader (with HVMs)
and directly with the VMs (with PV).

-dulloor

Signed-off-by : Dulloor <dulloor@xxxxxxxxx>

+struct xen_vnode_info {
+    uint8_t mnode_id;  /* physical node vnode is allocated from */
+    uint32_t start;    /* start of the vnode range (in pages) */
+    uint32_t end;             /* end of the vnode range (in pages) */
+};
Is there a particular reason you made the start and end members 32bit only?
This effectively limits the amount of memory to 16TB, which is not that
far from being used (if not larger NUMA machines already shipping with
this amount of memory).
So can you push these variables to 64 bits?
+struct xen_domain_numa_info {
+    uint8_t version;    /* Interface version */
+    uint8_t type;       /* VM memory allocation scheme (see above) */
+
+    uint8_t nr_vcpus;
+    uint8_t nr_vnodes;
The same for here. I'd like to see at least nr_vcpus to be prepared for more than 256 vCPUs. Please keep in mind that if Dom0 is also NUMA aware, by default the whole host resources are first given to Dom0, so the NUMA info should not be restricted to the size of a typical guest only.

Regards,
Andre.

--
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 448-3567-12


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