From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Christoph Egger" <Christoph.Egger@amd.com>
Subject: Re: [PATCH 2/4] [HVM] introduce CPU affinity for
	allocate_physmap call
Date: Mon, 13 Aug 2007 14:59:31 +0200
Message-ID: <200708131459.31305.Christoph.Egger@amd.com>
References: <C2E5F147.14154%keir@xensource.com>
Mime-Version: 1.0
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <C2E5F147.14154%keir@xensource.com>
Content-Disposition: inline
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: xen-devel@lists.xensource.com
Cc: Andre Przywara <andre.przywara@amd.com>, Keir Fraser <keir@xensource.com>
List-Id: xen-devel@lists.xenproject.org

On Monday 13 August 2007 12:30:15 Keir Fraser wrote:
> On 13/8/07 11:02, "Andre Przywara" <andre.przywara@amd.com> 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.

Except Xen bumps major version number to 4 ? :-)

You are worrying about PV guests that lag behind with syncing
pulic headers such as NetBSD/Xen ?

> In this case we  could steal bits from address_bits field and create a pa=
ir
> 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.=20
> Better to pass a vcpu_id and let Xen work out the most appropriate physic=
al
> 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?

Making struct xen_machphys_mapping NUMA-aware is also a no-go, right?
It would additionally need a min_mfn and a vnodeid member.

Oh, and how should the guest query how many vnode's exist?


=2D-=20
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Gesch=E4ftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplement=E4r:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Gesch=E4ftsf=FChrer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy