From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: REGRESSION [PATCH v2 08/13] libxc: Check
 xc_domain_maximum_gpfn for negative return values
Date: Fri, 27 Mar 2015 10:52:07 +0000
Message-ID: <1427453527.13935.108.camel@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> <551474F9.5060705@citrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
Received: from mail6.bemta3.messagelabs.com ([195.245.230.39])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <Ian.Campbell@citrix.com>) id 1YbS78-0005jx-Fh
	for xen-devel@lists.xenproject.org; Fri, 27 Mar 2015 11:07:46 +0000
In-Reply-To: <551474F9.5060705@citrix.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org, ian.jackson@eu.citrix.com
List-Id: xen-devel@lists.xenproject.org

On Thu, 2015-03-26 at 21:07 +0000, Andrew Cooper wrote:
> 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 <konrad.wilk@oracle.com>
> >> 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 <ian.campbell@citrix.com>
> >> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 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.

Oops, so it does, I noticed that but didn't fully think through the
naming implications once I noticed all the callers being correctly
adjusted, sorry.

> 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.

Putting the fence posting back, which will involve adjusting the other
callers, is probably best and reflects the underlying hypercall.

I think maximum_gpfn+1 could be described as nr_gpfns if we wanted to go
the renaming route, or make a wrapper which did the +1, returning the
original to the expect semantics.

Konrad, will you take care of this one way or another?

Ian.