[libvirt] PATCH 0/2]: Fix CPU affinity management for NR_CPUS > 1024

The RHEL-6 Alpha kernels have defined NR_CPUS=4096 The glibc static cpu_set_t data type used with sched_[gs]etaffinity() has been sized with # define __CPU_SETSIZE 1024 So any attempt to use sched_[gs]etaffinity() with a static cpu_set_t on a RHEL-6 kernel ends up with -EINVAL, even if the machine does not physically have > 1024 CPUs. The syscall mandates that the cpu set arg is large enough to hold entire of NR_CPUS. Fairly recent gLibc's now provide an alternative dynamically allocated cpu_set_t data type, where the app tells glibc how many CPUs it has to be able to hold. Great, except, the kernel does not tell userspace what NR_CPUS it has been compiled with. So apps have to a pick a starting size, try the sched_[gs]etaffinity() call, catch EINVAL, enlarge the cpuset, repeat, repeat, repeat until it works. This was going to be horrible to put into the qemu driver code, so I've introduced a new util/processinfo.[h,c] file providing APis for getting/setting CPU affinity that use the dynamically allocate mask libvirt defines in its public API. Daniel