 
	
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH for-xen-4.5] libxl: Allow copying smaller bitmap into a larger one
 On 11/21/2014 06:12 AM, Wei Liu wrote: On Thu, Nov 20, 2014 at 04:27:34PM -0500, Boris Ostrovsky wrote: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 Instead, we should allow copying the (smaller) bitmap read by the parser and keep the rest of bytes in the destination map unmodified (zero in this case)What about copying large bitmap to a smaller one? Say, you migrate to a host whose number of cpus is smaller than the size of the source bitmap. Is this a valid use case? Should we have a "best effort" copy function? That is, size = min(source_size, destination_size) copy(source, destination, size) Right, I haven't thought about it for the reversed case. -boris In any case I think this is a regression and should be fixed for 4.5. Wei. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel 
 
 | 
|  | Lists.xenproject.org is hosted with RackSpace, monitoring our |