From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tamas K Lengyel Subject: Re: [PATCH v3 10/15] xen/arm: Data abort exception (R/W) mem_events. Date: Tue, 9 Sep 2014 15:08:00 +0200 Message-ID: References: <1409581329-2607-1-git-send-email-tklengyel@sec.in.tum.de> <1409581329-2607-11-git-send-email-tklengyel@sec.in.tum.de> <5404E02E.7010406@linaro.org> <540777F9.8020006@linaro.org> <540E1496.5040902@linaro.org> <1410254445.8217.53.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2118783478798991023==" Return-path: In-Reply-To: <1410254445.8217.53.camel@kazak.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: Ian Campbell Cc: Tim Deegan , Julien Grall , Ian Jackson , "xen-devel@lists.xen.org" , Stefano Stabellini , Andres Lagar-Cavilla , Jan Beulich , Daniel De Graaf , Tamas K Lengyel List-Id: xen-devel@lists.xenproject.org --===============2118783478798991023== Content-Type: multipart/alternative; boundary=001a113a96cafab5970502a19ff2 --001a113a96cafab5970502a19ff2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 9, 2014 at 11:20 AM, Ian Campbell wrote: > On Mon, 2014-09-08 at 13:41 -0700, Julien Grall wrote: > > > > On 03/09/14 14:56, Tamas K Lengyel wrote: > > > I'm not entirely sure I could easily extend > > > apply_one_level/apply_p2m_changes without significant changes and a > > > potential to affect something else along the way.. I can give it a try > > > though but I'm a bit hesitant.. Do you see an immediate performance > > > reason to try to hook it into those functions instead of keeping it > > > separate? The current function is pretty straight forward in what it is > > > doing as it is. > > > > I would like to avoid standalone function that manipulate the p2m. It > > will be easier to fix bug, hence the code if everything is using the > > same code. > > Agreed, having two functions which do essentially the same thing (walk > the p2m and manipulate it) is not good from a maintenance point of view. > There would need to be a more compelling reason for this than a worry > about breaking the existing code. > > Ian. > Fair enough. I'll get it in for the next iteration. Tamas --001a113a96cafab5970502a19ff2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 9, 2014 at 11:20 AM, Ian Campbell <Ian.Campbell@citr= ix.com> wrote:
On Mon, 2014-09-08 at 13:41 -0700, Julien Gra= ll wrote:
>
> On 03/09/14 14:56, Tamas K Lengyel wrote:
>=A0 =A0> I'm not entirely sure I could easily extend
> > apply_one_level/apply_p2m_changes without significant changes and= a
> > potential to affect something else along the way.. I can give it = a try
> > though but I'm a bit hesitant.. Do you see an immediate perfo= rmance
> > reason to try to hook it into those functions instead of keeping = it
> > separate? The current function is pretty straight forward in what= it is
> > doing as it is.
>
> I would like to avoid standalone function that manipulate the p2m. It<= br> > will be easier to fix bug, hence the code if everything is using the > same code.

Agreed, having two functions which do essentially the same thin= g (walk
the p2m and manipulate it) is not good from a maintenance point of view. There would need to be a more compelling reason for this than a worry
about breaking the existing code.

Ian.

Fair enough. I'l= l get it in for the next iteration.

Tamas

--001a113a96cafab5970502a19ff2-- --===============2118783478798991023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============2118783478798991023==--