|
[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)
>
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)
In any case I think this is a regression and should be fixed for 4.5.
Wei.
> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
> ---
> tools/libxl/libxl.c | 4 ++--
> tools/libxl/libxl_utils.c | 7 +++++++
> tools/libxl/libxl_utils.h | 2 ++
> 3 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index f7961f6..84fd2ca 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5319,7 +5319,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t
> domid, uint32_t vcpuid,
> if (rc)
> goto out;
>
> - libxl_bitmap_copy(ctx, &hard, cpumap_hard);
> + libxl_bitmap_copy_partial(ctx, &hard, cpumap_hard);
> flags = XEN_VCPUAFFINITY_HARD;
> }
> if (cpumap_soft) {
> @@ -5327,7 +5327,7 @@ int libxl_set_vcpuaffinity(libxl_ctx *ctx, uint32_t
> domid, uint32_t vcpuid,
> if (rc)
> goto out;
>
> - libxl_bitmap_copy(ctx, &soft, cpumap_soft);
> + libxl_bitmap_copy_partial(ctx, &soft, cpumap_soft);
> flags |= XEN_VCPUAFFINITY_SOFT;
> }
>
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 58df4f3..2a08bef 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -614,6 +614,13 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap
> *dptr,
> memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
> }
>
> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
> + const libxl_bitmap *sptr)
> +{
> + assert(dptr->size >= sptr->size);
> + memcpy(dptr->map, sptr->map, sptr->size * sizeof(*dptr->map));
> +}
> +
> void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
> libxl_bitmap *dptr,
> const libxl_bitmap *sptr)
> diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
> index 117b229..d4d0a51 100644
> --- a/tools/libxl/libxl_utils.h
> +++ b/tools/libxl/libxl_utils.h
> @@ -80,6 +80,8 @@ void libxl_bitmap_copy_alloc(libxl_ctx *ctx, libxl_bitmap
> *dptr,
> const libxl_bitmap *sptr);
> void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap *dptr,
> const libxl_bitmap *sptr);
> +void libxl_bitmap_copy_partial(libxl_ctx *ctx, libxl_bitmap *dptr,
> + const libxl_bitmap *sptr);
> int libxl_bitmap_is_full(const libxl_bitmap *bitmap);
> int libxl_bitmap_is_empty(const libxl_bitmap *bitmap);
> int libxl_bitmap_test(const libxl_bitmap *bitmap, int bit);
> --
> 1.7.1
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |