From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall 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:45:39 +0000 Message-ID: <54BF9F73.7080804@linaro.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 1YDufl-0002Cb-PX for xen-devel@lists.xenproject.org; Wed, 21 Jan 2015 12:46:13 +0000 Received: by mail-wg0-f42.google.com with SMTP id k14so39572585wgh.1 for ; Wed, 21 Jan 2015 04:46:12 -0800 (PST) In-Reply-To: <1421843785.13271.31.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 Cc: xen-devel@lists.xenproject.org, tim@xen.org, stefano.stabellini@citrix.com List-Id: xen-devel@lists.xenproject.org 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. Regards, -- Julien Grall