Please use this patch, in which length of bitmap is
(physinfo.max_cpu_id+1), rather than (physinfo.nr_cpus).
-dulloor
On Tue, Mar 23, 2010 at 12:41 PM, Dulloor <dulloor@xxxxxxxxx> wrote:
> I meant utils for **xenctl_cpumap**
>
> On Tue, Mar 23, 2010 at 12:40 PM, Dulloor <dulloor@xxxxxxxxx> wrote:
>> Fine, I agree with you both. Attached is a patch adding utils for
>> xenctl_bitmap (to libxc) and using the same in vcpu_(get|set)affinity.
>> For the guest-numa interface, I will see if I can use xenctl_cpumap.
>>
>> -dulloor
>>
>> On Tue, Mar 23, 2010 at 7:05 AM, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
>> wrote:
>>> On 23/03/2010 10:10, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>>
>>>>>>> Dulloor <dulloor@xxxxxxxxx> 22.03.10 18:44 >>>
>>>>> Motivation for using xenctl_cpumask in Xen interfaces :
>>>>> - xenctl_cpumap is just 4 bytes smaller than static xenctl_cpumask for
>>>>> 128 cpus (128 would be good for quite some time). However, the new
>>>>
>>>> I don't buy this (we're already building for 256 CPUs, looking forward
>>>> to further bump this in the not too distant future), and I'm generally
>>>> opposed to introducing hard coded limits in a public interface.
>>>
>>> We should use xenctl_cpumask everywhere for specifying physical CPU bitmaps,
>>> even into guest NUMA interfaces if appropriate. I don't really care if it is
>>> a bit harder to use than a static bitmap.
>>>
>>> -- Keir
>>>
>>>
>>>
>>
>
cpumap-utils.patch
Description: Text Data
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|