From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756632AbcBILsc (ORCPT ); Tue, 9 Feb 2016 06:48:32 -0500 Received: from foss.arm.com ([217.140.101.70]:39784 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756294AbcBILsb (ORCPT ); Tue, 9 Feb 2016 06:48:31 -0500 Subject: Re: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP To: Tsahee Zidenberg References: <1454922699-16785-1-git-send-email-antoine.tenart@free-electrons.com> <1454922699-16785-3-git-send-email-antoine.tenart@free-electrons.com> <56B8B45D.1020902@arm.com> <20160209085633.GA5388@kwain> <20160209090131.GB5388@kwain> <56B9ACE2.1060200@arm.com> <56B9B1B5.5070106@arm.com> Cc: Antoine Tenart , catalin.marinas@arm.com, will.deacon@arm.com, "linux-arm-kernel@lists.infradead.org" , Ronen Shitrit , Thomas Petazzoni , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Barak Wasserstrom From: Marc Zyngier Organization: ARM Ltd Message-ID: <56B9D20A.8010709@arm.com> Date: Tue, 9 Feb 2016 11:48:26 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/02/16 10:13, Tsahee Zidenberg wrote: > On 9 February 2016 at 11:30, Marc Zyngier wrote: >> >> On 09/02/16 09:14, Tsahee Zidenberg wrote: >>> >>> >>> On 9 February 2016 at 11:09, Marc Zyngier >> > wrote: >>> >>> On 09/02/16 09:01, Antoine Tenart wrote: >>> > On Tue, Feb 09, 2016 at 09:56:33AM +0100, Antoine Tenart wrote: >>> >> Hi Marc, >>> >> >>> >> On Mon, Feb 08, 2016 at 03:29:33PM +0000, Marc Zyngier wrote: >>> >>> On 08/02/16 09:11, Antoine Tenart wrote: >>> >>> >>> >>>> + gic: gic@f0100000 { >>> >>>> + compatible = "arm,gic-v3"; >>> >>>> + reg = <0x0 0xf0200000 0x0 0x10000>, /* GIC Dist */ >>> >>>> + <0x0 0xf0280000 0x0 0x200000>, /* GICR */ >>> >>>> + <0x0 0xf0100000 0x0 0x2000>; /* GICC */ >>> >>>> + interrupt-controller; >>> >>>> + #interrupt-cells = <3>; >>> >>>> + }; >>> >>> >>> >>> Something is wrong here. Either you are missing GICH and GICV (assuming >>> >>> you have legacy support), or you have an extra GICC region (which >>> >>> doesn't make sense on its own). >>> >> >>> >> I'll add the missing regions. >>> > >>> > Hmm, in fact the GICC region shouldn't be there. I'll make some tests >>> > and remove it. >>> >>> If you have a GICv3 with legacy support, you will probably have GICC, >>> GICH and GICV. Linux itself will only use GICD and GICR, but it needs at >>> least GICV to be able to virtualize GICv2 guests. And GICV is not >>> allowed to exist without GICC and GICH, so I really recommend that you >>> keep GICC around. >>> >>> >>> We use the GIC without legacy support (we disable it in early boot >>> stages), so I think removing the GICC region is the better solution. >> >> Disabling legacy support doesn't mean that: >> - the HW isn't present >> - the associated regions are not useful >> > By "disabling lecgacy support in early boot" I don't just mean that > ARE bit will be set, but it will actually be RAO/WI. There will be no > way for SW to enable it and use these registers (which, sadly, means > that there will be no way to enable gicv2 virtualization). If you > insist - I will dig up the supposed location of GICV and GICH - yet it > will be both untested and entirely unusable. Just to make sure you are not missing the point: ARE==1 does *not* mean that GICV is unusable. Quite the opposite. It only makes it illegal to use GICC and GICH, but leaves GICV usable for a guest. So the real question is: do you have any additional HW that would actively prevent GICV from being used? If the answer to that is "no", and assuming your GICv3 implementation is compliant with the architecture, then GICV will be usable, and you should document all 3 regions. Thanks, M. -- Jazz is not dead. It just smells funny...