RE: "cpus" config parameter broken?

["Dan Magenheimer" <dan.magenheimer@oracle.com>]

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 == "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" <dan.magenheimer@oracle.com> 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
> 
> 
>