Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp214834imm; Fri, 21 Sep 2018 13:03:08 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaqFxixkVJ3d/szE51GSjHG+TSkJE3UhEE6yIf60+aYrWOEHUZPZw2TYb9huiN3deb5aIvV X-Received: by 2002:a63:f51:: with SMTP id 17-v6mr15601063pgp.100.1537560188283; Fri, 21 Sep 2018 13:03:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537560188; cv=none; d=google.com; s=arc-20160816; b=YVLJEPR0i5nmz54brOiyR3fWKbOua3ssKaUt1sYPbHF5jM+Z+0vHBGKaYCdj6Shekn aLO1hj9siB0KtMiuZLTFSnTBZTKT9m4aVAdTF+BXu8mRvVm4mEMNjbN5Vm0lCJSzxMrw cMkoe+Q2iibYkEceioxKL8ZeFEe2dTVnZrLJu3VdOvLjd2eV0XDF/WNyYkyXhMDyQ+pU GPPk68KSsDBFdEa8kGwPr4bYX2jreDHwgydo3XaGw9U1quxwCaArchIw4e9aZPuX39Dt eYZJgTNOy1cmkzwhCBh4H7kcgY47ceD1GtvFCq2AYSiEUkIyu/MUVAQvGRtHQwcp3yX+ ZRgQ== 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; bh=E8K0xwrWDlezOusFPW1ACwVC6N3fAjTRdnO4DzlR18s=; b=CfGQIPZ9N9KkGwsSUwmoDZL3swpMIChRP0dYN9qGFfRR0Nln9TkyPy/OS887ODNIrs 9TKDI3a7h803eg+hVM3NVQBDzBAMyvUPin4hoEvjIm/wD7zPutWeXhYAu1R5m3O61hCT GJl7BkHXzUuhRm1xcPjcAwXOulPiQ2BM/JY0IXcUniVanX0SIzEPIaxU5CVdiJAjeu3J B4EEM2I9FGY1K4/qvJoJ7Ibmaq/g0U3jPEam4tcsjNQdL9UtcGkw9kKyOk8lfWmoRDsK Gtyq1U0YSxfcjIOJQMqb3HcPw9SMDamKvhf+ru+asuSL6kuJz/zomn3HC2nAPU6Mn/Cb L3JA== 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 u6-v6si26455523pld.256.2018.09.21.13.02.52; Fri, 21 Sep 2018 13:03:08 -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 S2391398AbeIVBum (ORCPT + 99 others); Fri, 21 Sep 2018 21:50:42 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:41254 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390726AbeIVBum (ORCPT ); Fri, 21 Sep 2018 21:50:42 -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 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 Cc: Ard Biesheuvel , Jeremy Linton , Jeffrey Hugo , Thomas Gleixner , Jason Cooper 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(-) -- 2.18.0