From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andre Przywara Subject: Re: [vNUMA v2][PATCH 2/8] public interface Date: Tue, 3 Aug 2010 14:40:22 +0200 Message-ID: <4C580E36.9040808@amd.com> References: <1BEA8649F0C00540AB2811D7922ECB6C9338B4CC@orsmsx507.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dulloor Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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 > > +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