Re: [PATCH for-xen-4.5] libxl: Allow copying smaller bitmap into a larger one

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 11/25/2014 06:41 AM, Dario Faggioli wrote:
> On Tue, 2014-11-25 at 11:15 +0000, Wei Liu wrote:
>> And here it is.
>>
>> Boris, can you give it a shot?
>>
>> ---8<---
>>  From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
>> From: Wei Liu <wei.liu2@citrix.com>
>> Date: Tue, 25 Nov 2014 10:59:47 +0000
>> Subject: [PATCH] libxl: allow copying between bitmaps of different sizes
>>
>> When parsing bitmap objects JSON parser will create libxl_bitmap map of the
>> smallest size needed.
>>
>> This can cause problems when saved image file specifies CPU affinity.  For
>> example, if 'vcpu_hard_affinity' in the saved image has only the first CPU
>> specified, just a single byte will be allocated and libxl_bitmap->size will be
>> set to 1.
>>
>> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
>> since the destination bitmap is created for maximum number of CPUs.
>>
>> We could allocate that bitmap of the same size as the source, however, it is
>> later passed to xc_vcpu_setaffinity() which expects it to be sized to the max
>> number of CPUs
>>
>> To fix this issue, introduce an internal function to allowing copying between
>> bitmaps of different sizes. Note that this function is only used in
>> libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
>> libxl_bitmap_copy as well there's no need to replace those invocations.  NUMA
>> placement logic comes into effect when no vcpu / node pinning is provided, so
>> it always operates on bitmap of the same sizes (that is, size of maximum
>> number of cpus /nodes).
>>
>> Reported-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
>> Signed-off-by: Wei Liu <wei.liu2@citrix.com>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Dario Faggioli <dario.faggioli@citrix.com>
>>
> If this end up being the approach, it can have the following:
>
> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>