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

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 11/25/2014 06:41 AM, Dario Faggioli wrote:
> On Tue, 2014-11-25 at 11:15 +0000, Wei Liu wrote:
> > And here it is.
> >
> > Boris, can you give it a shot?
> >
> > ---8<---
> >  From 77531e31d239887b9f36c03e434300bc30683092 Mon Sep 17 00:00:00 2001
> > From: Wei Liu <wei.liu2@xxxxxxxxxx>
> > Date: Tue, 25 Nov 2014 10:59:47 +0000
> > Subject: [PATCH] libxl: allow copying between bitmaps of different sizes
> >
> > 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
> >
> > 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>
> If this end up being the approach, it can have the following:
>
> Reviewed-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
Tested-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>



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