RE: "cpus" config parameter broken?

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

> >>> - 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.
> 
> Ah yes. But then the offline CPUs get masked out in 
> vcpu_set_affinity(), and
> the affinity mask is then rejected if the remaining CPU set is empty.

I see you are correct that the v->cpu_affinity bits never do get set.
But the mask is not rejected -- but instead some bits are silently
ignored -- if there are both online and offline cpus in the list.
So:

   cpus="0,3"

on a 2p machine will currently set only one bit (bit 0) on a 2p but

   xm vcpu-pin domid all "0,3"

will set two bits.  Whereas

   cpus="2-3"

will cause an error on a 2p but

   xm vcpu-pin domid all "2-3"

will not.  This would become relevant if the "cpus" parameter
were preserved across a migration (rather than v->cpu_affinity),
which is what led to my original confusion.

So modulo-izing the cpus parameter code will eliminate this
case, but I still wonder if vcpu_set_affinity should reject any
mask that has bits set beyond max_pcpu instead of silently
ignoring those bits.  Seems like an accident waiting to happen
and indeed I got bitten by it.

Which is why I proposed tightening the definition of all affinity
masks (and strings representing masks) to "if you try to enable
a bit in the cpumask that refers to a non-existent processor, you
will get an error"

Thanks,
Dan