From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: "cpus" config parameter broken? Date: Thu, 10 Jan 2008 11:38:28 -0700 Message-ID: <20080110113828859.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 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) - the modulo behavior currently implemented in "xm vcpu-pin" and the config file "cpus" parameter should be removed, and - if cpu values are specified by "xm vcpu-pin" or "cpus" beyond the number of physical cpus, the xm command should fail. 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 > = > = >