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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

CC'ing Dario...

On Mon, Nov 24, 2014 at 10:41:27AM +0000, 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)
> > 
> 
> 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