From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2619C07E9B for ; Wed, 21 Jul 2021 09:53:45 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 5ED7060FDA for ; Wed, 21 Jul 2021 09:53:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5ED7060FDA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id EF7B04B107; Wed, 21 Jul 2021 05:53:44 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYjZsP4aUdAf; Wed, 21 Jul 2021 05:53:43 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 45AA04B108; Wed, 21 Jul 2021 05:53:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id DEA444B103 for ; Wed, 21 Jul 2021 05:53:41 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snqs3owooYvP for ; Wed, 21 Jul 2021 05:53:41 -0400 (EDT) Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id F21164B107 for ; Wed, 21 Jul 2021 05:53:40 -0400 (EDT) Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 03EEC60FDA; Wed, 21 Jul 2021 09:53:40 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m68v3-00Efzw-VK; Wed, 21 Jul 2021 10:53:38 +0100 Date: Wed, 21 Jul 2021 10:53:37 +0100 Message-ID: <87czrc2dsu.wl-maz@kernel.org> From: Marc Zyngier To: Jianyong Wu Subject: Re: [PATCH] doc/arm: take care restore order of GICR_* in ITS restore In-Reply-To: <20210721092019.144088-1-jianyong.wu@arm.com> References: <20210721092019.144088-1-jianyong.wu@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: jianyong.wu@arm.com, james.morse@arm.com, andre.przywara@arm.com, lushenming@huawei.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, justin.he@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: justin.he@arm.com, kvm@vger.kernel.org, linux-doc@vger.kernel.org, andre.przywara@arm.com, linux-kernel@vger.kernel.org, lushenming@huawei.com, kvmarm@lists.cs.columbia.edu X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu On Wed, 21 Jul 2021 10:20:19 +0100, Jianyong Wu wrote: > > When restore GIC/ITS, GICR_CTLR must be restored after GICR_PROPBASER > and GICR_PENDBASER. That is important, as both of GICR_PROPBASER and > GICR_PENDBASER will fail to be loaded when lpi has enabled yet in > GICR_CTLR. Keep the restore order above will avoid that issue. > Shout it out at the doc is very helpful that may avoid lots of debug work. But that's something that is already mandated by the architecture, isn't it? See "5.1 LPIs" in the architecture spec: If GICR_PROPBASER is updated when GICR_CTLR.EnableLPIs == 1, the effects are UNPREDICTABLE. [...] If GICR_PENDBASER is updated when GICR_CTLR.EnableLPIs == 1, the effects are UNPREDICTABLE. The point of this documentation is to make it explicit what is *not* covered by the architecture. Anything that is in the architecture still applies, and shouldn't be overlooked. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8F1ADC636CA for ; Wed, 21 Jul 2021 10:37:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5BA0561009 for ; Wed, 21 Jul 2021 10:37:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237773AbhGUJze (ORCPT ); Wed, 21 Jul 2021 05:55:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:43468 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238344AbhGUJND (ORCPT ); Wed, 21 Jul 2021 05:13:03 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 03EEC60FDA; Wed, 21 Jul 2021 09:53:40 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m68v3-00Efzw-VK; Wed, 21 Jul 2021 10:53:38 +0100 Date: Wed, 21 Jul 2021 10:53:37 +0100 Message-ID: <87czrc2dsu.wl-maz@kernel.org> From: Marc Zyngier To: Jianyong Wu Cc: james.morse@arm.com, andre.przywara@arm.com, lushenming@huawei.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, justin.he@arm.com Subject: Re: [PATCH] doc/arm: take care restore order of GICR_* in ITS restore In-Reply-To: <20210721092019.144088-1-jianyong.wu@arm.com> References: <20210721092019.144088-1-jianyong.wu@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: jianyong.wu@arm.com, james.morse@arm.com, andre.przywara@arm.com, lushenming@huawei.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, justin.he@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Wed, 21 Jul 2021 10:20:19 +0100, Jianyong Wu wrote: > > When restore GIC/ITS, GICR_CTLR must be restored after GICR_PROPBASER > and GICR_PENDBASER. That is important, as both of GICR_PROPBASER and > GICR_PENDBASER will fail to be loaded when lpi has enabled yet in > GICR_CTLR. Keep the restore order above will avoid that issue. > Shout it out at the doc is very helpful that may avoid lots of debug work. But that's something that is already mandated by the architecture, isn't it? See "5.1 LPIs" in the architecture spec: If GICR_PROPBASER is updated when GICR_CTLR.EnableLPIs == 1, the effects are UNPREDICTABLE. [...] If GICR_PENDBASER is updated when GICR_CTLR.EnableLPIs == 1, the effects are UNPREDICTABLE. The point of this documentation is to make it explicit what is *not* covered by the architecture. Anything that is in the architecture still applies, and shouldn't be overlooked. Thanks, M. -- Without deviation from the norm, progress is not possible.