From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v3 ]libxl: allow to set more than 31 vcpus Date: Fri, 01 Jun 2012 12:47:44 +0200 Message-ID: <1338547664.31901.54.camel@Abyss> References: <1338532541.31901.10.camel@Abyss> <1338540279.31901.17.camel@Abyss> <1338541118.17466.36.camel@zakaz.uk.xensource.com> <1338543157.31901.27.camel@Abyss> <1338543666.17466.55.camel@zakaz.uk.xensource.com> <1338546187.31901.45.camel@Abyss> <1338547136.17466.77.camel@zakaz.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5283609742334525823==" Return-path: In-Reply-To: <1338547136.17466.77.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "Zhang, Yang Z" , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org --===============5283609742334525823== Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Upd1/X7cFHC2FPw0qNG/" --=-Upd1/X7cFHC2FPw0qNG/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2012-06-01 at 11:38 +0100, Ian Campbell wrote:=20 > > Anyway, I just tried 25 and 33 and 65, and creation of the domain worke= d > > without raising any errors! Then I double-checked, and saw that, in the > > 'above 16' cases, Xen deliberately paused a lot of VCPUs. Also, if I lo= g > > into the guest /proc/cpuinfo reports only CPUs 0 and 32 (and 64 in the > > 65 VCPUs case). >=20 > All 64 online? >=20 I see all of them from the host (xl vcpu-list) but a kind of random number of them from the guest... > It might be that the issue being fixed here only manifests on HVM. I'm > not really sure how 64 would work otherwise since cur_vcpus in the IDL > is definitely an int, which is what needs fixing! >=20 and in fact, I agreed with that part of the patch. Also, yes, I'm trying PV but can try HVM as well and see what happens. > libxl__build_post is also probably buggy with max_vcpus > > nr-bits-in(curr_vcpus) and from the looks of it it just overflows off > the end(!), which is also fixed here... >=20 What I can do is trying again with the patch applied, and if it still behaves weird I'll go seeing what might be still missing. > > "max. number of cpus supported by hypervisor" to be different from the > > actual number of physical processors, and I was sort-of mislead by the > > machine I use to test Xen every day (where that is actually happening!)= . > > If it is not like that, I guess I can agree with you on this change. >=20 > It's certainly supposed to be "get max. number of physical cpus", quite > how that relates to the actual number of physical cpus I'm not sure. >=20 > It's definitely not something to do with virtual cpus (for which there > is a limit, but not this one...) >=20 Ok, with that "physical" you're putting there, I see and agree it could be useful untie it from the "virtual world". :-) Thanks and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-Upd1/X7cFHC2FPw0qNG/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk/IndAACgkQk4XaBE3IOsRerQCfZLYguulHdITcWLDlQtHO4d4M PJcAoJItTYH0bW+1qJ7/Lv69E6ljimLG =OBeB -----END PGP SIGNATURE----- --=-Upd1/X7cFHC2FPw0qNG/-- --===============5283609742334525823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============5283609742334525823==--