[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 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)
> 

Here is some more thoughts on this issue:

This API is used by VCPU placement and NUMA placement logic in libxl. To
fix the breakage, we don't necessary need to expose new API or change
API behaviour, we only need to have a internal function to do it.

The reversed case (large bitmap to small one) is not valid in libxl, as
in the pinning will fail. But bitmap copy happens before that, we would
still need to deal with that. Dario, can you provide some input on
the expected behaviour?

The partial copy function should explicitly zero-out all remaining bits.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.