Received: by 10.213.65.68 with SMTP id h4csp481155imn; Tue, 13 Mar 2018 10:23:44 -0700 (PDT) X-Google-Smtp-Source: AG47ELvojaueCoTMLzK3fTrv+6XnDkh0CVKsjwSS8kuvBnLI7CF9xXcckrrcu0jwipCLuaIELI1y X-Received: by 10.98.196.84 with SMTP id y81mr1342323pff.11.1520961824309; Tue, 13 Mar 2018 10:23:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520961824; cv=none; d=google.com; s=arc-20160816; b=sLtmlH0cyaaacaAxDtmAW0r1Yu8kRJ/NYIhQlklWnpgTSv69j+Y8zR5GhmWJgiqB48 1wSXPuukWJOiz0NZRlobclN3IPDi4kkpLjtkptemxJ6GiEDKs/gLPqlOfkfzx3S03R0O DGar7nYtH72dkzP1uBAPXPaZ2yfkCmQWQUFbq5I0jlCxlmuG6bo0U4aGmxt9ej+Yk6gi rB1d0C6hnKyQ5rea+80GfgormDj6cjUG3CItGFPEi8OG1fAaJhmxFNSVGTqsYoBSyigN Z1csdiV0i6d/p2Sf0DCLVsLO1N/+o0aUnYBJ+sfEj+L2DfG+rJtw9nXwflw6Q6/2rLi7 Btww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=5MDJGD92hS3JsMn4m3MZRuqny4ScQtDAqfHPKmrdib0=; b=V0flD7MPnUYMPjdlrYNO9OInI9Sg55BEhUwcFzHhonmbfGEUSPT/MGiz1hPvmkE+Rb D+BLtfOOX9BZb4NoUcWfjmyYOuJJ9Lfun0ra8SI7EjdWrIuOZUM4dO3VfaBKghGECMKW Jrg/XQBpad3rmLjMa7EqtALTir9xu4mHEZ6VQvMgLw5MA9zJT4PSbP7JN0En14eJk058 p5m/2mhFOPKPoKCZuEF2/L4FHw6J+fyUM7UKlA3lZOtEqDxKRl1wRnyFjxJLXxkdGDPp 7Gb924aUtqavmkoamaWFGnR+xNwxPF1DedKEpN2AbOPzo4NkP8lsIrLlWCb2sBRa6Evw j2fw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b1-v6si434683plm.172.2018.03.13.10.23.29; Tue, 13 Mar 2018 10:23:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932462AbeCMRVO (ORCPT + 99 others); Tue, 13 Mar 2018 13:21:14 -0400 Received: from foss.arm.com ([217.140.101.70]:41976 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751496AbeCMRVN (ORCPT ); Tue, 13 Mar 2018 13:21:13 -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 868DD1596; Tue, 13 Mar 2018 10:21:13 -0700 (PDT) Received: from approximate.cambridge.arm.com (approximate.cambridge.arm.com [10.1.207.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 53AB73F487; Tue, 13 Mar 2018 10:21:12 -0700 (PDT) From: Marc Zyngier To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: Jason Cooper , Thomas Gleixner , Grzegorz Jaszczyk , Mark Rutland Subject: [PATCH 0/3] irqchip: GIC kexec/kdump improvement and workarounds Date: Tue, 13 Mar 2018 17:21:00 +0000 Message-Id: <20180313172103.24281-1-marc.zyngier@arm.com> X-Mailer: git-send-email 2.14.2 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As kexec and kdump are getting used a bit more intensively, I've been made aware of a number of shortcomings. The main gripe is from folks trying to launch a kdump kernel from within an interrupt handler. If using EOImode==1, things work as expected. If using EOImode==0 (such as in a guest), the secondary kernel hangs as the previous interrupt hasn't been EOI'd, and the active priority is still set. The first two patches are addressing this situation for both GICv2 and GICv3 by reseting the APRs to their default value. The last patch is introduced to workaround an annoying shortcoming on some GICv3 implementations, where LPIs cannot be disabled once they've been enabled. This completely kills the whole kexec story, as the secondary kernel will not be able to configure LPIs, and may experience random single bit corruption due to interrupts being made pending in the now reallocated pending tables. Fun! This is quite annoying in those (limited) situations where you'd like Linux to act as your bootloader. For this particular use case, we introduce a kernel command line option "irqchip.gicv3_nolpi=1", which will force the kernel to ignore LPIs altogether, leaving them intact to the secondary kernel to enjoy. This has proved to be quite useful on my Chromebook. I'd welcome any testing and reviewing. If nobody fundamentaly disagrees with this, I plan to get it merged in 4.17. Marc Zyngier (3): irqchip/gic-v2: Reset APRn registers at boot time irqchip/gic-v3: Reset APgRn registers at boot time irqchip/gic-v3: Allow LPIs to be disabled from the command line Documentation/admin-guide/kernel-parameters.txt | 8 +++++ arch/arm/include/asm/arch_gicv3.h | 41 +++++++++++++++++++------ drivers/irqchip/irq-gic-v3.c | 33 +++++++++++++++++++- drivers/irqchip/irq-gic.c | 17 ++++++---- 4 files changed, 82 insertions(+), 17 deletions(-) -- 2.14.2