From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH for-xen-4.5] libxl: Allow copying smaller bitmap into a larger one Date: Tue, 25 Nov 2014 09:57:54 -0500 Message-ID: <547498F2.70201@oracle.com> References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com> <20141124104127.GF30053@zion.uk.xensource.com> <20141124104703.GH30053@zion.uk.xensource.com> <54735343.1020208@oracle.com> <20141125103940.GC28315@zion.uk.xensource.com> <20141125111522.GD28315@zion.uk.xensource.com> <1416915667.7176.39.camel@Abyss> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1416915667.7176.39.camel@Abyss> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli , Wei Liu Cc: xen-devel@lists.xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com, stefano.stabellini@eu.citrix.com List-Id: xen-devel@lists.xenproject.org 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 >> 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 >> Signed-off-by: Wei Liu >> Cc: Ian Campbell >> Cc: Ian Jackson >> Cc: Dario Faggioli >> > If this end up being the approach, it can have the following: > > Reviewed-by: Dario Faggioli Tested-by: Boris Ostrovsky