On 09/02/16 10:13, Tsahee Zidenberg wrote: > On 9 February 2016 at 11:30, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >> >> On 09/02/16 09:14, Tsahee Zidenberg wrote: >>> >>> >>> On 9 February 2016 at 11:09, Marc Zyngier <marc.zyngier@xxxxxxx >>> <mailto:marc.zyngier@xxxxxxx>> 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... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
