|
[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 Tue, 2014-11-25 at 11:15 +0000, Wei Liu wrote:
> This will result in assertion in libxl_set_vcpuaffinity()->libxl_bitmap_copy()
> since the destination bitmap is created for maximum number of CPUs.
FYI I'm also seeing this with libvirt (on ARM, but I don't think that
matters) when the guest XML uses:
<vcpu placement='static' cpuset='0-7'>1</vcpu>
Results in:
libvirtd: libxl_utils.c:612: libxl_bitmap_copy: Assertion `dptr->size
== sptr->size' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb67f9420 (LWP 3881)]
0xb6ab7f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) bt
#0 0xb6ab7f96 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
#1 0xb6ac5f8a in raise () from /lib/arm-linux-gnueabihf/libc.so.6
#2 0xb6ac8428 in abort () from /lib/arm-linux-gnueabihf/libc.so.6
#3 0xb6ac101e in __assert_fail () from
/lib/arm-linux-gnueabihf/libc.so.6
#4 0xb16caeb4 in libxl_bitmap_copy (ctx=<optimized out>,
dptr=<optimized out>, sptr=<optimized out>) at libxl_utils.c:612
#5 0xb16af15c in libxl_set_vcpuaffinity (ctx=0x2, domid=3065494508,
vcpuid=0, cpumap_hard=0xb67f8668, cpumap_soft=0x0) at libxl.c:5323
#6 0xb17195ae in libxlDomainSetVcpuAffinities () from
/opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
#7 0xb1719cf2 in libxlDomainStart () from
/opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
#8 0xb171b7c2 in libxlDomainCreateXML () from
/opt/libvirt/lib/libvirt/connection-driver/libvirt_driver_libxl.so
#9 0xb6d28630 in virDomainCreateXML () from
/opt/libvirt/lib/libvirt.so.0
[...snip...]
libxlDomainSetVcpuAffinities does:
libxl_bitmap map;
[...]
map.size = cpumaplen;
map.map = cpumap;
if (libxl_set_vcpuaffinity(priv->ctx, def->id, vcpu, &map) != 0) {
http://libvirt.org/git/?p=libvirt.git;a=blob;f=src/libxl/libxl_domain.c;h=9c622910547ada174a3d787c76c8bb076c9a75c3;hb=HEAD#l1059
Applying this libxl patch fixes things.
I don't think we've explicitly outlawed looking "inside" a libxl_bitmap
in this way anywhere, so I think libvirtd is within its rights to do so,
but it does highlight that we need to be mindful within libxl that
people may not be using libxl_cpu_bitmap_alloc.
>
> 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
>
> To fix this issue, introduce an internal function to allowing copying between
> bitmaps of different sizes. Note that this function is only used in
> libxl_set_vcpuaffinity at the moment. Though NUMA placement logic invoke
> libxl_bitmap_copy as well there's no need to replace those invocations. NUMA
> placement logic comes into effect when no vcpu / node pinning is provided, so
> it always operates on bitmap of the same sizes (that is, size of maximum
> number of cpus /nodes).
>
> Reported-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
> Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx>
> Cc: Ian Campbell <ian.campbell@xxxxxxxxxx>
> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Cc: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
> ---
> This fixes a regression for 4.5. Can't think of obvious risk.
> ---
> tools/libxl/libxl.c | 4 ++--
> tools/libxl/libxl_internal.h | 11 +++++++++++
> tools/libxl/libxl_utils.c | 15 +++++++++++++++
> 3 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index de23fec..1e9da10 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5320,7 +5320,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_best_effort(gc, &hard, cpumap_hard);
> flags = XEN_VCPUAFFINITY_HARD;
> }
> if (cpumap_soft) {
> @@ -5328,7 +5328,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_best_effort(gc, &soft, cpumap_soft);
> flags |= XEN_VCPUAFFINITY_SOFT;
> }
>
> diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
> index 4361421..a38f695 100644
> --- a/tools/libxl/libxl_internal.h
> +++ b/tools/libxl/libxl_internal.h
> @@ -3617,6 +3617,17 @@ static inline void libxl__update_config_vtpm(libxl__gc
> *gc,
> libxl_device_##type##_copy(CTX, DA_p, (dev)); \
> })
>
> +/* This function copies X bytes from source to destination bitmap,
> + * where X is the smaller of the two sizes.
> + *
> + * If destination's size is larger than source, the extra bytes are
> + * untouched.
> + *
> + * XXX This is introduced to fix a regression for 4.5. It shall
> + * be revisited in 4.6 time frame.
> + */
> +void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
> + const libxl_bitmap *sptr);
> #endif
>
> /*
> diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
> index 58df4f3..3e1ba17 100644
> --- a/tools/libxl/libxl_utils.c
> +++ b/tools/libxl/libxl_utils.c
> @@ -614,6 +614,21 @@ void libxl_bitmap_copy(libxl_ctx *ctx, libxl_bitmap
> *dptr,
> memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
> }
>
> +/* This function copies X bytes from source to destination bitmap,
> + * where X is the smaller of the two sizes.
> + *
> + * If destination's size is larger than source, the extra bytes are
> + * untouched.
> + */
> +void libxl__bitmap_copy_best_effort(libxl__gc *gc, libxl_bitmap *dptr,
> + const libxl_bitmap *sptr)
> +{
> + int sz;
> +
> + sz = dptr->size < sptr->size ? dptr->size : sptr->size;
> + memcpy(dptr->map, sptr->map, sz * sizeof(*dptr->map));
> +}
> +
> void libxl_bitmap_copy_alloc(libxl_ctx *ctx,
> libxl_bitmap *dptr,
> const libxl_bitmap *sptr)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |