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] [PATCH 1 of 3] To be able to support arbitrary numbers o

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1 of 3] To be able to support arbitrary numbers of physical cpus it was necessary to
From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
Date: Fri, 08 Oct 2010 10:03:55 +0200
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Fri, 08 Oct 2010 01:04:30 -0700
Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=ts.fujitsu.com; i=juergen.gross@xxxxxxxxxxxxxx; q=dns/txt; s=s1536b; t=1286525038; x=1318061038; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<4CAED06B.1070504@xxxxxxxxxxxxxx>|Date:=20 Fri,=2008=20Oct=202010=2010:03:55=20+0200|From:=20Juergen =20Gross=20<juergen.gross@xxxxxxxxxxxxxx>|MIME-Version: =201.0|To:=20Ian=20Campbell=20<Ian.Campbell@xxxxxxxxxx> |CC:=20Stefano=20Stabellini=20<stefano.stabellini@xxxxxxx ix.com>,=20=0D=0A=20"xen-devel@xxxxxxxxxxxxxxxxxxx"=20<xe n-devel@xxxxxxxxxxxxxxxxxxx>|Subject:=20Re:=20[Xen-devel] =20[PATCH=201=20of=203]=20To=20be=20able=20to=20support =20arbitrary=09numbers=0D=0A=20of=20physical=20cpus=20it =20was=20necessary=20to|References:=20<cfce8e7555059a646c 65.1286286315@nehalem1>=09<alpine.DEB.2.00.1010061215380. 2440@kaball-desktop>=20<1286372485.23155.12849.camel@zaka z.uk.xensource.com>|In-Reply-To:=20<1286372485.23155.1284 9.camel@xxxxxxxxxxxxxxxxxxxxxx> |Content-Transfer-Encoding:=207bit; bh=YXYV2dAv7i+4Gt2r0r9hrz/RUaCXHmY5vOpoyFMyivg=; b=vM/acVlx3MLvCzEnGkRlxNCUiGi5qwnDPhp0T6J4nffGL9wVHgAFYeIY 0IeHr8tmXZ6QMKEqxTGjJBPyYmrAuXlwxMiv7guiSKTGtHiTHDcv2tMgO ESIw1dzlcjMIvFdcokWXV90VN9MzqxzAdEePAwSAyMMwgvJMCEtB6pWTL 5oDtms9wAibalY4+A+UiePexx8KkRo4j2yUKUaHYA8n7vIPGVxj/9AL4p HHCsI00vuVtfVl5Br7EQH2ex5R7Tl;
Domainkey-signature: s=s1536a; d=ts.fujitsu.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=SyclmVu7uJl8RiS5RWYhdWA92dVMDYa/F0txDcTZF++9nNJYtbj8ce8G LSKjxc3cfrTY4BZqrCKaOEngvKiy33itUoqyLFY3UOZE1PmNszadOTm0i PpE1W9VWcbT/lpWy9ZFn6GQ57kuffhO105ViKbXOJSaUOPUFo2zzPLyTu J6ecBADRZrw/6+TDV/CIbi2TpBhB6kPQxPPJhemJDw61I0xIBH2HYhvU5 tkO3/mUa4a6j5Lo39v32mkf6TYFHD;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1286372485.23155.12849.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Fujitsu Technology Solutions
References: <cfce8e7555059a646c65.1286286315@nehalem1> <alpine.DEB.2.00.1010061215380.2440@kaball-desktop> <1286372485.23155.12849.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100913 Iceowl/1.0b1 Icedove/3.0.7
On 10/06/10 15:41, Ian Campbell wrote:
On Wed, 2010-10-06 at 12:21 +0100, Stefano Stabellini wrote:
On Tue, 5 Oct 2010, Juergen Gross wrote:
diff -r fe3018c6976d -r cfce8e755505 tools/libxl/libxl_internal.h
--- a/tools/libxl/libxl_internal.h      Mon Oct 04 12:52:14 2010 +0100
+++ b/tools/libxl/libxl_internal.h      Tue Oct 05 14:19:13 2010 +0200
@@ -239,7 +239,6 @@
  _hidden char *libxl__domid_to_name(libxl__gc *gc, uint32_t domid);
  _hidden char *libxl__poolid_to_name(libxl__gc *gc, uint32_t poolid);

-
    /* holds the CPUID response for a single CPUID leaf
     * input contains the value of the EAX and ECX register,
     * and each policy string contains a filter to apply to

we don't need this change


diff -r fe3018c6976d -r cfce8e755505 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c  Mon Oct 04 12:52:14 2010 +0100
+++ b/tools/libxl/xl_cmdimpl.c  Tue Oct 05 14:19:13 2010 +0200
@@ -3616,12 +3616,11 @@
  static void vcpupin(char *d, const char *vcpu, char *cpu)
  {
      libxl_vcpuinfo *vcpuinfo;
-    libxl_physinfo physinfo;
      uint64_t *cpumap = NULL;

      uint32_t vcpuid, cpuida, cpuidb;
      char *endptr, *toka, *tokb;
-    int i, nb_vcpu, cpusize;
+    int i, nb_vcpu, cpusize, cpumapsize;

      vcpuid = strtoul(vcpu,&endptr, 10);
      if (vcpu == endptr) {
@@ -3634,12 +3633,13 @@

      find_domain(d);

-    if (libxl_get_physinfo(&ctx,&physinfo) != 0) {
-        fprintf(stderr, "libxl_get_physinfo failed.\n");
+    if ((cpusize = xc_get_max_cpus(ctx.xch)) == 0) {
+        fprintf(stderr, "xc_get_maxcpus failed.\n");
          goto vcpupin_out1;
      }

You shouldn't be calling xc functions directly from xl_cmdimpl.c.
The basic rule is: libxl clients (such as xl) shouldn't need to call any
library functions other than libxenlight's functions.
You can add a libxl_get_max_cpus function though.

Maybe we should add libxl_cpumap_alloc_phys which returns a libxl_cpumap
big enough to hold all physical CPUs, there are a few places within
libxl itself which might benefit from this, e.g. libxl_list_cpupool and
libxl_list_vcpu both call xc_get_max_cpus and then use the result as a
parameter to libxl_cpumap_alloc.

Actually, given that libxl_cpumap is only ever used for PCPUs perhaps
alloc should just always return a suitably sized map and there's no need
for the size parameter to libxl_cpumap_alloc? Is there any plausible
potential use for a libxl_cpumap of nrVCPU rather than nrPCPU ?

Currently there seems to be no demand for cpumasks larger than nrPCPU.
Changinf libxl_cpumap_alloc to allocate just the correct size seems
appropriate.
I think I'll do this in my planned cpumask rework.


Juergen

--
Juergen Gross                 Principal Developer Operating Systems
TSP ES&S SWE OS6                       Telephone: +49 (0) 89 3222 2967
Fujitsu Technology Solutions              e-mail: juergen.gross@xxxxxxxxxxxxxx
Domagkstr. 28                           Internet: ts.fujitsu.com
D-80807 Muenchen                 Company details: ts.fujitsu.com/imprint.html

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

<Prev in Thread] Current Thread [Next in Thread>