From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: REGRESSION [PATCH v2 08/13] libxc: Check xc_domain_maximum_gpfn for negative return values Date: Thu, 26 Mar 2015 21:07:05 +0000 Message-ID: <551474F9.5060705@citrix.com> References: <1426724659-23999-1-git-send-email-konrad.wilk@oracle.com> <1426724659-23999-9-git-send-email-konrad.wilk@oracle.com> <1426783678.21742.75.camel@citrix.com> <20150319185416.GC21217@x230.dumpdata.com> <1426844888.21742.107.camel@citrix.com> <20150320143434.GD17267@l.oracle.com> <20150320144925.GA22093@l.oracle.com> <1426863624.21742.213.camel@citrix.com> <20150320154555.GD2085@l.oracle.com> <1426870986.21742.226.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YbEzf-00045i-V0 for xen-devel@lists.xenproject.org; Thu, 26 Mar 2015 21:07:12 +0000 In-Reply-To: <1426870986.21742.226.camel@citrix.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: Ian Campbell , Konrad Rzeszutek Wilk Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com List-Id: xen-devel@lists.xenproject.org On 20/03/15 17:03, Ian Campbell wrote: > On Fri, 2015-03-20 at 11:45 -0400, Konrad Rzeszutek Wilk wrote: >> From 45bd7cd377b0b8364757cc2bc0bd8d6a13523a97 Mon Sep 17 00:00:00 2001 >> From: Konrad Rzeszutek Wilk >> Date: Fri, 13 Mar 2015 14:57:44 -0400 >> Subject: [PATCH] libxc: Check xc_domain_maximum_gpfn for negative return >> values >> >> Instead of assuming everything is always OK. We stash >> the gpfns value as an parameter. Since we use it in three >> of places we might as well update xc_domain_maximum_gpfn >> to do the right thing. >> >> Suggested-by: Ian Campbell >> Signed-off-by: Konrad Rzeszutek Wilk > Acked + applied along with the rest of the series, thanks, This change as unfortunately causes a regression in migration v2, because the fenceposting has changed and the function no longer returns the maximum gpfn. It returns one past the maximum gpfn. It would appear that migration v2 was the only consumer which actually want the max gpfn. Can we either rename the function to accurately name the value it returns (although I am out of ideas as to what this might be), or undo the fenceposting change so that it continues to return the value it claims to return. ~Andrew