From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v8 3/4] xen/arm: Make gic-v2 code handle hip04-d01 platform Date: Tue, 03 Mar 2015 15:42:36 +0000 Message-ID: <54F5D66C.2060205@linaro.org> References: <54F5CE4C.80909@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Frediano Ziglio , Ian Campbell , Stefano Stabellini , Tim Deegan Cc: Zoltan Kiss , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 03/03/15 15:36, Frediano Ziglio wrote: >> >> Hello Frediano, >> >> On 03/03/15 11:19, Frediano Ziglio wrote: >>> The GIC in this platform is mainly compatible with the standard >>> GICv2 beside: >>> - ITARGET is extended to 16 bit to support 16 CPUs; >>> - SGI mask is extended to support 16 CPUs; >>> - maximum supported interrupt is 510; >> >> 510 is not a multiple of 32. Is it normal? >> >> This will result to having nr_lines = 512. What happen is we are trying >> to access IRQ 510 and 511? >> > > I don't know. I think it's the same reason why in xen/arch/arm/gic.c the limit for irq is 1021 and not 1024 (see "if ( likely(irq >= 16 && irq < 1021) )" line) IRQ 1021-1023 are reserved by the GIC as spurious interrupt. If I understand correctly what you say, IRQ 510-511 may be considered for spurious interrupt? If so, the check (irq >= 16 && irq < 1021) needs to be changed. >> Also, is it possible to have GICH.VirtualID >= 510? >> > > I think so, GICH have the same interface of normal GICv2. But some offsets are different... so I'd like a confirmation based on some spec. For instance on GICv2 if we use some VirtualID (1021-1023) the behavior is unpredictable. So if you have the a similar things on your board we may need to restrict the number of VirtualID in order to avoid introduce a possible host denial from a guest. >> [..] >> >>> -DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC) >>> - .dt_match = gicv2_dt_match, >>> - .init = gicv2_init, >>> +DT_DEVICE_START(hip04gic, "GIC-HIP04", DEVICE_GIC) >>> + .dt_match = hip04gic_dt_match, >>> + .init = hip04gic_init, >>> DT_DEVICE_END >> >> Please keep the same indentation as before. >> > > I was wondering why the indentation is different. Ok I'm not sure why ... but it looks like we use the same indentation everywhere for DT_DEVICE_START. Regards, -- Julien Grall