[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 2/4] [HVM] introduce CPU affinity for allocate_physmap call


  • To: Andre Przywara <andre.przywara@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir@xxxxxxxxxxxxx>
  • Date: Mon, 13 Aug 2007 11:30:15 +0100
  • Delivery-date: Mon, 13 Aug 2007 03:30:54 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcfdlO+3LgnQXkmIEdymlgAX8io7RQ==
  • Thread-topic: [Xen-devel] [PATCH 2/4] [HVM] introduce CPU affinity for allocate_physmap call

On 13/8/07 11:02, "Andre Przywara" <andre.przywara@xxxxxxx> 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


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.