Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2014707imm; Thu, 27 Sep 2018 06:12:54 -0700 (PDT) X-Google-Smtp-Source: ACcGV61lG6Vi7vJxq5rs8B8x1FeIB+54Livmqb7QiaPtrZTTczQYAv9025EbypxvvLaCuDj67uN9 X-Received: by 2002:a65:4c43:: with SMTP id l3-v6mr10180582pgr.451.1538053974262; Thu, 27 Sep 2018 06:12:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538053974; cv=none; d=google.com; s=arc-20160816; b=YW8ZQjihZlRnXv4gmV0GU0ImpRgc3tAhI5JPNnRPzdM93YYLjciNiKqAZzxO5dxebi Uji34g3U/Qm2n1sWjPWx7sAKzUwalLuWt6X+TDdHy4dkEdAWdKJTdWeDIw1EiJG7lvcn YVOxQCU6v0Qj9GcN+OjDWnPoz776UyU985RPHqfd054lTBJkjSv7n72se8f0SDgKzZ5/ 4wPJYW4zYMA0zWDVC5YWokmjrWqvv9qANQ1c1vUvkqL2HWszHBJgZeyD1s6jL7IG/c/d cAQOYz3KnBqQ6Fv3/0SfLCPcKDENR7OzqKBGsT/XcQ3wRKdEocHoVly9NxArWX3Z5g9q 53pg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-language :accept-language:in-reply-to:references:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=kJiYrRtxDjxtUf6PmDPj99GiDUyeOzi47RWw6bzrLu0=; b=hGZHk/ewg7Po66OhZEMpIa+6+A59FcnHVI6gZb7xCruBbfyh39i2PHy5w+XnbeMbiL 9R4Xwrdf3M2MKwm5rOLj2a697TzHfxCJUnvC75WP0XmeJX9Skks1iwXOjDWc41HyR1/m dpmb26fHTexlmoAWfOufQPvYTmqWwJt+8UAh7nRSQj7PDKuocwN5D31/iCg3QPh8FKLM oee/B2e2p5JgX2Czq/Bkclis74/h9Tfc3zAgdZ+pX/Ue6t4V9+cM7HXfLvXxP5MGuPkO U8/Zz5lvkF73hxXzj3R6sVq/gKNGKSbZUVEJrPcMcqKD9OPWqeIDUi/abfrDdkNYwJyZ 5noQ== 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 r39-v6si2007741pld.218.2018.09.27.06.12.38; Thu, 27 Sep 2018 06:12:54 -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 S1727453AbeI0Tad (ORCPT + 99 others); Thu, 27 Sep 2018 15:30:33 -0400 Received: from mgwkm04.jp.fujitsu.com ([202.219.69.171]:15611 "EHLO mgwkm04.jp.fujitsu.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726953AbeI0Tad (ORCPT ); Thu, 27 Sep 2018 15:30:33 -0400 X-Greylist: delayed 672 seconds by postgrey-1.27 at vger.kernel.org; Thu, 27 Sep 2018 15:30:31 EDT Received: from kw-mxoi2.gw.nic.fujitsu.com (unknown [192.168.231.133]) by mgwkm04.jp.fujitsu.com with smtp id 4f66_1136_2b7e1e32_61dc_4c12_be9f_1a07cea6c2d7; Thu, 27 Sep 2018 22:01:04 +0900 Received: from g01jpfmpwkw03.exch.g01.fujitsu.local (g01jpfmpwkw03.exch.g01.fujitsu.local [10.0.193.57]) by kw-mxoi2.gw.nic.fujitsu.com (Postfix) with ESMTP id 84D0BAC0171 for ; Thu, 27 Sep 2018 22:01:03 +0900 (JST) Received: from G01JPEXCHKW16.g01.fujitsu.local (G01JPEXCHKW16.g01.fujitsu.local [10.0.194.55]) by g01jpfmpwkw03.exch.g01.fujitsu.local (Postfix) with ESMTP id 74348BD675F; Thu, 27 Sep 2018 22:01:02 +0900 (JST) Received: from G01JPEXMBKW03.g01.fujitsu.local ([10.0.194.67]) by g01jpexchkw16 ([10.0.194.55]) with mapi id 14.03.0352.000; Thu, 27 Sep 2018 22:01:02 +0900 From: "Zhang, Lei" To: 'Marc Zyngier' , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" CC: Jeffrey Hugo , Thomas Gleixner , Jason Cooper , Jeremy Linton , Ard Biesheuvel Subject: RE: [PATCH 00/10] GICv3 support for kexec/kdump on EFI systems Thread-Topic: [PATCH 00/10] GICv3 support for kexec/kdump on EFI systems Thread-Index: AQHUUeYpisctXpEhGkyHhq24W3KoEKUEH5Sw Date: Thu, 27 Sep 2018 13:01:01 +0000 Message-ID: <8898674D84E3B24BA3A2D289B872026A6A005F4A@G01JPEXMBKW03> References: <20180921195954.21574-1-marc.zyngier@arm.com> In-Reply-To: <20180921195954.21574-1-marc.zyngier@arm.com> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-securitypolicycheck: OK by SHieldMailChecker v2.2.3 x-shieldmailcheckerpolicyversion: FJ-ISEC-20140219 x-originating-ip: [10.18.70.198] Content-Type: text/plain; charset="iso-2022-jp" MIME-Version: 1.0 X-SecurityPolicyCheck-GC: OK by FENCE-Mail X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Marc > -----Original Message----- > From: linux-arm-kernel > [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of Marc > Zyngier > Sent: Saturday, September 22, 2018 5:00 AM > To: linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org > Cc: Jeffrey Hugo; Thomas Gleixner; Jason Cooper; Jeremy Linton; Ard > Biesheuvel > Subject: [PATCH 00/10] GICv3 support for kexec/kdump on EFI systems > > 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]. We have done the test on our chip A64FX that When a write changes EnableLPI bit from 0 to 1, this bit becomes RES1. The result is that the kexec operation successfully works on our chip, and PCI based on LPI also works after kexec. For detail: We did "kexec -e" command, and the message, "Using preallocated redistributor tables", was shown. After kexec, we can use our ssd normally. Test environment CPU: A64FX Kernel version: v4.19 rc4 base https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=irq/gicv3-kdump 8bc67da irqchip/gic-v3-its: Allow use of LPI tables in reserved memory kexec version:kexec-tools-2.0.14-17.2.el7.aarch64 Tested-by: Lei Zhang Thanks a lot. Best Regards, Lei,Zhang FUJITSU LIMITED.