From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Liu Subject: Re: [PATCH for-xen-4.5] libxl: Allow copying smaller bitmap into a larger one Date: Mon, 24 Nov 2014 10:47:03 +0000 Message-ID: <20141124104703.GH30053@zion.uk.xensource.com> References: <1416518854-5284-1-git-send-email-boris.ostrovsky@oracle.com> <20141124104127.GF30053@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20141124104127.GF30053@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Boris Ostrovsky Cc: wei.liu2@citrix.com, ian.campbell@citrix.com, Dario Faggioli , stefano.stabellini@eu.citrix.com, ian.jackson@eu.citrix.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org 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.