From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 2/4] [HVM] introduce CPU affinity for allocate_physmap call Date: Mon, 13 Aug 2007 11:30:15 +0100 Message-ID: References: <46C02C33.8030301@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <46C02C33.8030301@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andre Przywara , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 13/8/07 11:02, "Andre Przywara" wrote: > @@ -35,6 +35,7 @@ > #define XENMEM_increase_reservation 0 > #define XENMEM_decrease_reservation 1 > #define XENMEM_populate_physmap 6 > +#define XENMEM_DEFAULT_CPU ((unsigned int)-1) > struct xen_memory_reservation { > > /* > @@ -66,6 +67,7 @@ struct xen_memory_reservation { > * Unprivileged domains can specify only DOMID_SELF. > */ > domid_t domid; > + unsigned int cpu; > }; We cannot change the size of existing hypercall structures. In this case we could steal bits from address_bits field and create a pair of 16-bit fields from it. Also, a physical cpu id is not a great fit for this hypercall -- it is meaningless to most guests who do not see the physical cpu map. Better to pass a vcpu_id and let Xen work out the most appropriate physical cpu id based on the vcpu's affinity. Or have a concept of per-guest 'virtual node identifiers' and pass a 'uint16_t vnodeid'. The latter might actually be a nice abstraction -- it'd be good to know other people's thoughts on this? -- Keir