From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: "cpus" config parameter broken? Date: Thu, 10 Jan 2008 14:10:24 -0700 Message-ID: <20080110141024093.00000003216@djm-pc> References: Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , Ian Pratt , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org I have blinders on since this discussion started with my trying to figure out the syntax and semantics for the "cpus" parameter as used in a config file, but: > > - the v->cpu_affinity mask should never have bits set for > = > This is already the case. No, with the cpus parameter, it is currently possible to set bits in v->cpu_affinity mask for processors that don't exist. Perhaps this is the real bug then. I will spin a patch to implement the modulo behavior from "xm vcpu-set" for the parsing of the cpus parameter and all will be well. Thanks, Dan > -----Original Message----- > From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > Sent: Thursday, January 10, 2008 1:50 PM > To: dan.magenheimer@oracle.com; Ian Pratt; = > xen-devel@lists.xensource.com > Subject: Re: [Xen-devel] "cpus" config parameter broken? > = > = > = > = > = > On 10/1/08 18:38, "Dan Magenheimer" = > wrote: > = > > As a logical consequence: > > > > - the v->cpu_affinity mask should never have bits set for > > processors that don't exist on the current physical system > > (although all bits set =3D=3D "any" is probably an OK exception) > = > This is already the case. > = > > - the modulo behavior currently implemented in "xm vcpu-pin" > > and the config file "cpus" parameter should be removed, and > = > Possibly. > = > > - if cpu values are specified by "xm vcpu-pin" or "cpus" > > beyond the number of physical cpus, the xm command should > > fail. > = > Again, possibly. I don't see much wrong with a liberal = > interpretation of > otherwise incorrect cpu config parameters though. If we = > tighten things up > then we need to make it easier to access CPU topology info from within > domain config files. > = > -- Keir > = > > Agreed? > > > >> -----Original Message----- > >> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] > >> Sent: Wednesday, January 09, 2008 12:17 PM > >> To: dan.magenheimer@oracle.com; Ian Pratt; > >> xen-devel@lists.xensource.com > >> Subject: Re: [Xen-devel] "cpus" config parameter broken? > >> > >> > >> On 9/1/08 18:40, "Dan Magenheimer" = > wrote: > >> > >>> My opinion: CPU affinity/restriction should NOT be preserved > >>> across migration. Or if it is, it should only be preserved > >>> when the source and target have the same number of pcpus > >>> (thus allowing save/restore to work OK). Or maybe it should > >>> only be preserved for save/restore and not for migration. > >>>>>>>>>>>> Comments? <<<<<<<<<<<<<<<<<<<<<<<<<<<<< > >> > >> I agree with that. Unless save/restore is on the same machine > >> (identified in > >> some way) or at least has identical CPU topology as far as = > we can see. > >> Otherwise some higher-level entity needs to be smart enough > >> to work out > >> affinity during restore and issue the correct 'xm' commands > >> (or equivalent). > >> > >> -- Keir > >> > >> > >> > > > = > = >