From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756893AbcBINyy (ORCPT ); Tue, 9 Feb 2016 08:54:54 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:34414 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754974AbcBINyw (ORCPT ); Tue, 9 Feb 2016 08:54:52 -0500 MIME-Version: 1.0 In-Reply-To: <56B9D20A.8010709@arm.com> 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> <56B9D20A.8010709@arm.com> From: Tsahee Zidenberg Date: Tue, 9 Feb 2016 15:54:31 +0200 Message-ID: Subject: Re: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP To: Marc Zyngier 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9 February 2016 at 13:48, Marc Zyngier wrote: > 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. > O.K. will add to next version. > Thanks, > > M. > -- > Jazz is not dead. It just smells funny... From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tsahee Zidenberg Subject: Re: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP Date: Tue, 9 Feb 2016 15:54:31 +0200 Message-ID: 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> <56B9D20A.8010709@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <56B9D20A.8010709-5wv7dgnIgG8@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Marc Zyngier Cc: Antoine Tenart , catalin.marinas-5wv7dgnIgG8@public.gmane.org, will.deacon-5wv7dgnIgG8@public.gmane.org, "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" , Ronen Shitrit , Thomas Petazzoni , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Barak Wasserstrom List-Id: devicetree@vger.kernel.org On 9 February 2016 at 13:48, Marc Zyngier wrote: > 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. > O.K. will add to next version. > Thanks, > > M. > -- > Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: tsahee@annapurnalabs.com (Tsahee Zidenberg) Date: Tue, 9 Feb 2016 15:54:31 +0200 Subject: [PATCH 2/3] arm64: dts: add the Alpine v2 EVP In-Reply-To: <56B9D20A.8010709@arm.com> 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> <56B9D20A.8010709@arm.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 9 February 2016 at 13:48, Marc Zyngier wrote: > 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 at 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. > O.K. will add to next version. > Thanks, > > M. > -- > Jazz is not dead. It just smells funny...