From patchwork Fri Sep 21 19:59:44 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marc Zyngier X-Patchwork-Id: 10610893 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id DCF75161F for ; Fri, 21 Sep 2018 20:02:45 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CD39F2DDFE for ; Fri, 21 Sep 2018 20:02:45 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C1A8F2DE18; Fri, 21 Sep 2018 20:02:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 43A022DE1D for ; Fri, 21 Sep 2018 20:02:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Message-Id:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=0Dt/2vstHkRMPRKlopyFoeyCQUsTB3S8E58tNvlF7WM=; b=SAo F4hFZEQHpw0gSrb/LonWRmR5TcVfOIhd1RMmwdq9UxKzqMwWNHsC4072sz2F29iigy4mQwSnt6ZfH ov/T4nzIwoEqhWEIXey6TxXpl+IgUgmNG3AAmMcZueKBBUL8cETewJlmHosBSyKjSQ+JOJrv8NIGg mIPjoPuyetWoolgDmRG2YtgWYdxoBcAAHrOidIJWbr86vgQ2rCc4DTBi9bxGS/VlMr5s7SegBP/3E JxYMvOAYm6dDXgbT9XRbpojYZAYMZOkDGgYDU1ugCNvrqoR76mwL1jV5jiuGeqfwbin+RpSlV0fdH CGAeH5J4ALqDN1a/piDu6wIquPxAe0Q==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1g3RdO-00040r-UR; Fri, 21 Sep 2018 20:02:38 +0000 Received: from foss.arm.com ([217.140.101.70]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1g3RbJ-0002zx-Pm for linux-arm-kernel@lists.infradead.org; Fri, 21 Sep 2018 20:00:34 +0000 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 E27D218A; Fri, 21 Sep 2018 13:00:17 -0700 (PDT) Received: from localhost.localdomain (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 961EF3F5BD; Fri, 21 Sep 2018 13:00:17 -0700 (PDT) From: Marc Zyngier To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH 00/10] GICv3 support for kexec/kdump on EFI systems Date: Fri, 21 Sep 2018 20:59:44 +0100 Message-Id: <20180921195954.21574-1-marc.zyngier@arm.com> X-Mailer: git-send-email 2.18.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180921_130029_913831_E88C05AA X-CRM114-Status: GOOD ( 13.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jeffrey Hugo , Thomas Gleixner , Jason Cooper , Jeremy Linton , Ard Biesheuvel MIME-Version: 1.0 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP The GICv3 architecture has the remarkable feature that once LPI tables have been assigned to redistributors and that LPI delivery is enabled, there is no guarantee that LPIs can be turned off (and most implementations do not allow it), nor can it be reprogrammed to use other tables. This is a bit of a problem for kexec, where the secondary kernel completely looses track of the previous allocations. If the secondary kernel doesn't allocate the tables exactly the same way, no LPIs will be delivered by the GIC (which continues to use the old tables), and memory previously allocated for the pending tables will be slowly corrupted, one bit at a time. The workaround for this is based on a series[1] by Ard Biesheuvel, which adds the required infrastructure for memory reservations to be passed from one kernel to another using an EFI table. This infrastructure is then used to register the allocation of GIC tables with EFI, and allow the GIC driver to safely reuse the existing programming if it detects that the tables have been correctly registered. On non-EFI systems, there is not much we can do. This has been tested on a TX2 system both as a host and a guest. I'd welcome additional testing of different HW. For convenience, I've stashed a branch containing the whole thing at [2]. [1] https://marc.info/?l=linux-efi&m=153754757208163&w=2 [2] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gicv3-kdump Marc Zyngier (10): irqchip/gic-v3-its: Change initialization ordering for LPIs irqchip/gic-v3-its: Consolidate LPI_PENDBASE_SZ usage irqchip/gic-v3-its: Split property table clearing from allocation irqchip/gic-v3-its: Move pending table allocation to init time irqchip/gic-v3-its: Keep track of property table's PA and VA irqchip/gic-v3-its: Allow use of pre-programmed LPI tables irqchip/gic-v3-its: Use pre-programmed redistributor tables with kdump kernels irqchip/gic-v3-its: Check that all RDs have the same property table irqchip/gic-v3-its: Register LPI tables with EFI config table irqchip/gic-v3-its: Allow use of LPI tables in reserved memory drivers/irqchip/irq-gic-v3-its.c | 249 ++++++++++++++++++++++------- drivers/irqchip/irq-gic-v3.c | 20 ++- include/linux/irqchip/arm-gic-v3.h | 4 +- 3 files changed, 208 insertions(+), 65 deletions(-) Tested-by: Jeremy Linton Tested-by: Bhupesh Sharma Tested-by: Lei Zhang