From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH 04/10] xen/arm: vgic-v3: Don't check the size when we ignore the write/read as zero Date: Wed, 21 Jan 2015 12:50:34 +0000 Message-ID: <1421844634.13271.40.camel@citrix.com> References: <1421684957-29884-1-git-send-email-julien.grall@linaro.org> <1421684957-29884-5-git-send-email-julien.grall@linaro.org> <1421769455.10440.306.camel@citrix.com> <54BE9341.7010307@linaro.org> <1421776670.10440.330.camel@citrix.com> <54BEA393.5060207@linaro.org> <1421842295.13271.16.camel@citrix.com> <54BF9B75.5030100@linaro.org> <1421843785.13271.31.camel@citrix.com> <54BF9F73.7080804@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YDuk7-0002RZ-Uy for xen-devel@lists.xenproject.org; Wed, 21 Jan 2015 12:50:44 +0000 In-Reply-To: <54BF9F73.7080804@linaro.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Julien Grall Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com List-Id: xen-devel@lists.xenproject.org On Wed, 2015-01-21 at 12:45 +0000, Julien Grall wrote: > On 21/01/15 12:36, Ian Campbell wrote: > > On Wed, 2015-01-21 at 12:28 +0000, Julien Grall wrote: > > > >>> 3) Accesses which are valid but which do not correctly emulate according > >>> to the features of the virtual gic which we are exposing can log if we > >>> think it is useful to do so. > >> > >> I gave a look to the code. We have few registers we don't correctly > >> emulate. The current behavior seems to be inconsistent, we either inject > >> a data abort (such as ICPENDR) or ignore the error (such as ICACTIVER). > >> > >> Shall we take a domain_crash approach (as bad_width) or inject a data abort? > > > > I think for these cases since we do update and/or return > > rank->iactive/ipend a debug log and continue is appropriate. > > > > Assuming we do need to do something more than track the status of > > i{active,pend}, which I expect we do -- e.g. to cancel or inject as > > appropriate. > > This code is actually buggy as we never use those fields. I have a patch > to drop iactive/ipend fields as we will unlikely handle ACTIVE/PENDING > status via those bit. We already track in different way as we already > have tracking per vIRQ. > > My plan was to replace them with an error log and maybe a data abort. > If you think a debug message is enough, I could go this way. Though, it > may be more difficult for a developer to find the actual error if there > is may logs. The best thing to do would be to implement them properly. I'm not sure that switching to an abort of any sort would be a good idea now that we've pretended to implement them a bit, logging then RAZ/WI might be an ok change. Ian.