From patchwork Thu Sep 10 09:54:27 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 7153131 Return-Path: X-Original-To: patchwork-kvm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id D469E9F72C for ; Thu, 10 Sep 2015 09:54:40 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C5A0F20925 for ; Thu, 10 Sep 2015 09:54:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9EA4220927 for ; Thu, 10 Sep 2015 09:54:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753149AbbIJJye (ORCPT ); Thu, 10 Sep 2015 05:54:34 -0400 Received: from foss.arm.com ([217.140.101.70]:33200 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750741AbbIJJyb (ORCPT ); Thu, 10 Sep 2015 05:54:31 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3E60A317; Thu, 10 Sep 2015 02:54:42 -0700 (PDT) Received: from [10.1.209.148] (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6634C3F21A; Thu, 10 Sep 2015 02:54:29 -0700 (PDT) Message-ID: <55F15353.2000800@arm.com> Date: Thu, 10 Sep 2015 10:54:27 +0100 From: Marc Zyngier Organization: ARM Ltd User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Julien Grall , Thomas Gleixner , Jason Cooper , Pranavkumar Sawargaonkar CC: kvm@vger.kernel.org, Eric Auger , linux-kernel@vger.kernel.org, Jiang Liu , Christoffer Dall , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, Stefano Stabellini , Ian Campbell Subject: Re: [PATCH v4 3/4] irqchip: GIC: Convert to EOImode == 1 References: <1440604845-28229-1-git-send-email-marc.zyngier@arm.com> <1440604845-28229-4-git-send-email-marc.zyngier@arm.com> <55F08731.3050402@citrix.com> In-Reply-To: <55F08731.3050402@citrix.com> Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Julian, On 09/09/15 20:23, Julien Grall wrote: > Hi, > > I've been trying the latest linus/master (a794b4f), which include this > patch, as baremetal kernel on X-gene. This is failing on early boot > without much log. > > After bisecting the tree, I found the error coming from this patch. > While this patch is valid, it made me remembered that X-Gene (at least > the first version) as an odd GICv2. > > The GICC is divided in 2 area of 4K, each one aligned at a 64KB address. > This means that, the address of GICC_DIR won't be 0x1000 but 0x10000. Not really. I already mentioned that one a while ago: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/332249.html The first page of GIC is aliased over the first 64kB, and the second page aliased over the second 64kB. So you get a consistent mapping if you use (base + 0xF000) to address GICC. Also, the DT that's in mainline is showing a 4kB CPU interface, which doesn't enable EOImode==1. You must be using a firmware that's newer than mine, since I'm perfectly able to boot my Mustang with these patches. > We had the same issue on Xen when we did the first port of X-gene [1]. > Although, we choose to add a quirk in Xen for this platform in order to > map contiguously in the virtual memory the 2 part of GICC. > > Note that, back then, Ian suggested to extend the bindings to support a > such platform [2]. AFAICT, there was no follow-up on it. The main problem here is not to update the binding, but the fact that you *cannot* update the DT on x-gene (the firmware will replace your GIC node with what it thinks it is), and the APM guys can't be bothered to fix their stuff. In the meantime, can you give the following patch a shot? My Mustang is wired to a 4kB CPU interface, so I'll need your help to test it. Thanks, M. From f0f086a4462198a5a2ac840901d9b8fd23b25134 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Thu, 10 Sep 2015 10:23:45 +0100 Subject: [PATCH] irqchip/GIC: Add workaround for aliased GIC400 The GICv2 architecture mandates that the two 4kB GIC regions are contiguous, and on two separate physical pages. This doesn't work very well when PAGE_SIZE is 64kB. A relatively common hack to work around this is to alias each 4kB region over its own 64kB page. Of course in this case, the base address you want to use is not really the begining of the region, but base + 60kB (so that you get a contiguous 8kB region over two distinct pages). Normally, this would be describe in DT with a new property, but some HW is already out there, and the firmware makes sure that it will override whatever you put in the GIC node. Duh. And of course, said firmware source code is not available, despite being based on u-boot. The workaround is to detect the case where the CPU interface size is set to 128kB, and verify the aliasing by checking that the ID register for GIC400 (which is the only GIC wired this way so far) is the same at base and base + 0xF000. In this case, we update the GIC base address and let it roll. And if you feel slightly sick by looking at this, rest assured that I do too... Reported-by: Julien Grall Signed-off-by: Marc Zyngier Tested-by: Julien Grall --- drivers/irqchip/irq-gic.c | 45 ++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 40 insertions(+), 5 deletions(-) diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c index e6b7ed5..b62f2b2 100644 --- a/drivers/irqchip/irq-gic.c +++ b/drivers/irqchip/irq-gic.c @@ -1119,12 +1119,50 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start, #ifdef CONFIG_OF static int gic_cnt __initdata; +static bool gic_check_eoimode(struct device_node *node, void __iomem **base) +{ + struct resource cpuif_res; + + of_address_to_resource(node, 1, &cpuif_res); + + if (!is_hyp_mode_available()) + return false; + if (resource_size(&cpuif_res) < SZ_8K) + return false; + if (resource_size(&cpuif_res) == SZ_128K) { + u32 val; + + /* + * Verify that we have a GIC400 aliased over the first + * 64kB by checking the GICC_IIDR register. + */ + val = readl_relaxed(*base + GIC_CPU_IDENT); + if (val != 0x0202043B) + return false; + + val = readl_relaxed(*base + GIC_CPU_IDENT + 0xF000); + if (val != 0x0202043B) + return false; + + /* + * Move the base up by 60kB, so that we have a 8kB + * contiguous region, which allows us to use GICC_DIR + * at its normal offset. + */ + *base += 0xF000; + cpuif_res.start += 0xF000; + pr_warn("GIC: Adjusting CPU interface base to %pa", + &cpuif_res.start); + } + + return true; +} + static int __init gic_of_init(struct device_node *node, struct device_node *parent) { void __iomem *cpu_base; void __iomem *dist_base; - struct resource cpu_res; u32 percpu_offset; int irq; @@ -1137,14 +1175,11 @@ gic_of_init(struct device_node *node, struct device_node *parent) cpu_base = of_iomap(node, 1); WARN(!cpu_base, "unable to map gic cpu registers\n"); - of_address_to_resource(node, 1, &cpu_res); - /* * Disable split EOI/Deactivate if either HYP is not available * or the CPU interface is too small. */ - if (gic_cnt == 0 && (!is_hyp_mode_available() || - resource_size(&cpu_res) < SZ_8K)) + if (gic_cnt == 0 && !gic_check_eoimode(node, &cpu_base)) static_key_slow_dec(&supports_deactivate); if (of_property_read_u32(node, "cpu-offset", &percpu_offset))