From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: [PATCH v4 1/5] xen/arm: vgic-v2: Handle correctly
 byte write in ITARGETSR
Date: Fri, 23 Oct 2015 11:12:44 +0100
Message-ID: <1445595164.2374.104.camel@citrix.com>
References: <1444659760-24123-1-git-send-email-julien.grall@citrix.com>
	<1444659760-24123-2-git-send-email-julien.grall@citrix.com>
	<1445529185.2374.25.camel@citrix.com> <562910A1.5000606@citrix.com>
	<1445592803.2374.83.camel@citrix.com> <562A04C0.7050109@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.bemta5.messagelabs.com ([195.245.231.135])
	by lists.xen.org with esmtp (Exim 4.72)
	(envelope-from <prvs=7311588c8=Ian.Campbell@citrix.com>)
	id 1ZpZL6-0006fm-N5
	for xen-devel@lists.xenproject.org; Fri, 23 Oct 2015 10:12:48 +0000
In-Reply-To: <562A04C0.7050109@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: Julien Grall <julien.grall@citrix.com>, xen-devel@lists.xenproject.org
Cc: stefano.stabellini@eu.citrix.com
List-Id: xen-devel@lists.xenproject.org

On Fri, 2015-10-23 at 10:58 +0100, Julien Grall wrote:
> On 23/10/15 10:33, Ian Campbell wrote:
> > On Thu, 2015-10-22 at 17:36 +0100, Julien Grall wrote:
> > > On 22/10/15 16:53, Ian Campbell wrote:
> > > > On Mon, 2015-10-12 at 15:22 +0100, Julien Grall wrote:
> 
> [...]
> 
> > > > > 
> > > > > Furthermore, the body of the loop is retrieving the old target
> > > > > list
> > > > > using the index of the byte.
> > > > > 
> > > > > To avoid modifying too much the loop, shift the byte stored to
> > > > > the
> > > > > correct
> > > > > offset.
> > > > 
> > > > That might have meant a smaller patch, but it's a lot harder to
> > > > understand
> > > > either the result or the diff.
> > > 
> > > The size of the patch would have been the same. Although, it requires
> > > to
> > > modify the call to vgic_byte_read in the loop to access the correct
> > > interrupt.
> > > 
> > > I didn't try to spend to much time to modify the loop because the
> > > follow-up patch (#2) will rewrite the loop.
> > 
> > Since this patch is marked for backport then if we decided to take #2
> > then
> > that's probably ok, otherwise the state of the tree after just this
> > patch
> > is more relevant.
> > That's in itself probably a stronger argument for taking #2 than the
> > actual
> > functionality of #2 is.
> 
> This code is already complex and I don't think the loop modification would have
> make the code easier to read.
> 
> Although, my plan was to ask to backport the whole series once we exercise
> the code a bit in unstable. This is in order to fix 32-bit access on 64-bit
> register.

OK, if the whole series is going to be backported at once then the
maintainability of the intermediate states is not so critical.

Ian.