From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH 05/10] xen/arm: vgic-v3: Document the current restrictions Date: Tue, 20 Jan 2015 17:49:34 +0000 Message-ID: <54BE952E.6040304@linaro.org> References: <1421684957-29884-1-git-send-email-julien.grall@linaro.org> <1421684957-29884-6-git-send-email-julien.grall@linaro.org> <1421769643.10440.309.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 1YDcwG-0007OK-Am for xen-devel@lists.xenproject.org; Tue, 20 Jan 2015 17:50:04 +0000 Received: by mail-wi0-f175.google.com with SMTP id fb4so19980406wid.2 for ; Tue, 20 Jan 2015 09:50:02 -0800 (PST) In-Reply-To: <1421769643.10440.309.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 Hi Ian, On 20/01/15 16:00, Ian Campbell wrote: > On Mon, 2015-01-19 at 16:29 +0000, Julien Grall wrote: >> The current vGIC v3 driver doesn't fully implement GICv3 spec: >> - GICv3 backward compatibility is not supported (GICD_CTLR.ARE = 0) > > I think you meant GICv2 here as you did in the code. Yes. > In which case I believe this is optional in the spec, i.e. we can be > compliant and still not implement this. > > That's not to say it isn't desirable, but this is a TODO item, not a > spec non-conformity issue. Right, I should rename the section to TODO. >> - A processor can only access his own redistributor. For buggy >> assumption, the current code bank the redistributors MMIO. > > What assumption? It's not clear if you mean that a foreign redistributor > should not be accessible and is, or if it should be accessible and > isn't. Every redistributor (one per processor) are mapped in distinct MMIO region. Unlike the distributor, the redistributor is not banked. Our current implementation (see vgic_v3_rdistr_mmio_write) consider that the redistributor is banked and replicate n-times in the memory. If you give a look to the redistributor iniatialization (see Xen and Linux GICv3 code). The code will go through all the redistributors and check GICR_TYPER to see if the processor is associated to this redistributor. I'm not sure how the redistributor should behave if it's accessed by another processor. But I'm sure it's wrong to bank it. Regards, -- Julien Grall