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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DFA90C433FE for ; Sun, 6 Nov 2022 11:40:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=cCOV/n33Vv9jrltFUg+Lr5y7HrBk7G4wUgkku3Fc580=; b=rPM023jeWlX8Vp pHSKXsBmHF71acv3rzvPfXgMqG/mn0q3IgG5SVmJNH6W2lRWGY9lu0g0glmpvYvJrAohgH7tSyVTp zXZejX31Q84nfkWTEzGEpu7APmqk+9QSl7GxhtrwkbCGDcl3C1eTmPtRyczp8Ql78YS9JWC8xUvjT LTtclsjrcrHPD7TbXkm2ZtvCJ+Cg3Kh5bwzt8xpaGRl7Motv+eaZrP0DE1Ixala2OeyYPIhVBOWal A4+s1oQsKxOGD7Wyi/q5++y//xOcjcaOY5pWeBQAXfpgbTIAvuDGXTmm36hPqMfGoLDvRv142plbp IzF1evp1QJauyBYFT0ig==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ordzq-0087Oo-IH; Sun, 06 Nov 2022 11:39:26 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ordzn-0087O6-MY for linux-arm-kernel@lists.infradead.org; Sun, 06 Nov 2022 11:39:25 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 06BB360C41; Sun, 6 Nov 2022 11:39:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64B8EC433D6; Sun, 6 Nov 2022 11:39:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667734761; bh=j5davB5BdVKnE8L/+1zd1qKFRaHn+fGl2JRUSZzAVWc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=F2tqtfeEZ/EBh75z9wzFPbfkfll1EgY3eguwJXsQrIQsNFu1qIzVpNLFTGeWKUHNy wB/k3g5xnoMd1e2rbgbUZq7CU01gU//Ci0t7cyaIUU76PWLHbh//caTDKvVg81h4xQ 8wY6JGBx1/0tbmGyG1RsApjARXujVdqSMAHJwzYuPIenvY9su9UOiZ3YO/bNXRX/Pt yc2xkSTx1xZcGeAPslCEK0oG2MaMItgYKn3WVFfxENHcrpxlFO5vqmrS0evPKkdnYP jZ4PGpjvRw998/uEvfBSZ6yp/UM0Ch6dbXlk/bSa3SF7DblI9i2OY9TNsBBzdd+5v6 6IdzLmK0R3tIA== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ordzj-004Bpd-4R; Sun, 06 Nov 2022 11:39:19 +0000 Date: Sun, 06 Nov 2022 11:38:51 +0000 Message-ID: <87r0ygfh2s.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown Cc: Catalin Marinas , Will Deacon , Lorenzo Pieralisi , Mark Rutland , Sami Mujawar , Thomas Gleixner , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v1 00/18] arm64/nmi: Support for FEAT_NMI In-Reply-To: <20221104235453.870573-1-broonie@kernel.org> References: <20221104235453.870573-1-broonie@kernel.org> 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: broonie@kernel.org, catalin.marinas@arm.com, will@kernel.org, lpieralisi@kernel.org, mark.rutland@arm.com, Sami.Mujawar@arm.com, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221106_033923_835034_A5DFB377 X-CRM114-Status: GOOD ( 40.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 04 Nov 2022 23:54:35 +0000, Mark Brown wrote: > > This series enables the architecture and GIC support for the arm64 > FEAT_NMI and FEAT_GICv3_NMI extensions in host kernels. These introduce > support for a new category of interrupts in the architecture code which > we can use to provide NMI functionality, though the interrupts are in > fact maskable as the name would not imply. The GIC support was done by > Loreozo Pieralisi. > > There are two modes for using this FEAT_NMI, the one we use is the one > where any entry to ELn causes all interrupts including those with > superpriority to be masked by a new mask bit ALLINT.ALLINT on entry to > ELn until the mask is explicitly removed by software. We do this early > in the C entry code for anything that is not a superpriority interrupt, > those are handled without unmasking. Independent controls are provided > for this feature at each EL, usage at EL1 should not disrupt EL2 or EL3. > > Since we can mask these not quite NMIs a large portion of the series is > concerned with updating places where we really do not want to be taking > interrupts of any kind to add masking for NMIs. This masking is not > added to our standard interrupt masking operations since that would > result in widespread masking of NMIs which would undermine their value. > Given that there's a large amount of kernel code a good proportion of > which I'm not terribly familar with it is likely that this area of the > series needs attention in review as there may be be be areas that have > been missed or misunderstood. Can you at least clarify why the no-quite-NMI cannot follow the pattern established by the pseudo-NMI support? I would have expected the critical sections to strictly map between the two so-called-NMI implementations. > > In order to ensure that we do not have both pseudo NMIs and real NMIs > simultaneously enabled we disable NMIs if pseudo NMI support is enabled > in the kernel and has been requested on the command line, since pseudo > NMIs require explicit enablement it seemed most sensible to trust that > the user preferred them for some reason. > > Using this feature in KVM guests will require the implementation of vGIC > support which is not present in this series, and there is also no usage > of the feature at EL2. While FEAT_NMI does add a new writable register > ALLINT the value is already context switched for EL1 via SPSR_EL2.ALLINT > and we can't trap read access to the register so we don't manage the > write trap that is available in HCRX_EL2.TALLINT. Guests can read from > the register anyway and should only be able to affect their own state. ... and create some architectural state that is impossible to manage and migrate. Great. Frankly, we are accumulating a bunch of half implemented features (SME, SPE) for which there is no KVM support, and I don't think this is the correct direction of travel. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel