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@lists.xen.org http://lists.xen.org/xen-devel