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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 4574BC47247 for ; Fri, 8 May 2020 10:45:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1219120870 for ; Fri, 8 May 2020 10:45:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588934724; bh=WdRe9mFMH+MwGQROhSO9uud8y8TlpMsCgvbEDkfz00c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=Q3xT8UNqNmdIVkUPe0v7nU/GBnuCkg/RY43zP/5TfnuScSGm4ihtV+YSdocpt0mIy ZkPnOObCN7jnRa20pzOvmkMX6sO3iGhSHDFuiHCXuN82gTV9VTjyTJPgBnfBQsF5g9 YEe5Jr9TVcQs5ONL6pkcA2Om4klBgO9RRcTY1yAc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726864AbgEHKpX (ORCPT ); Fri, 8 May 2020 06:45:23 -0400 Received: from mail.kernel.org ([198.145.29.99]:57146 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726325AbgEHKpW (ORCPT ); Fri, 8 May 2020 06:45:22 -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 720B420870; Fri, 8 May 2020 10:45:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588934722; bh=WdRe9mFMH+MwGQROhSO9uud8y8TlpMsCgvbEDkfz00c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mKhKGqb60I7GBv1Wig9nzvzXREPjEEn5a2eWFiWmuF7sUGGZirnA2khX2F4V9wLur Phwq4fMdvW7kjKKSARnQoQjEbXPV27Ui9OYuUv+T28xXq65FFurVom8GzFHBQHXHUx szoNcHOG1Db3T/ihZG3pk/hDROQYuOFEDKAuMF5k= Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jX0VM-00AYzB-MZ; Fri, 08 May 2020 11:45:20 +0100 Date: Fri, 08 May 2020 11:45:11 +0100 Message-ID: <87ftca1z9k.wl-maz@kernel.org> From: Marc Zyngier To: Neeraj Upadhyay Cc: julien.thierry.kdev@gmail.com, linux-kernel@vger.kernel.org Subject: Re: Query regarding pseudo nmi support on GIC V3 and request_nmi() In-Reply-To: <2a0d5719-b2c7-1287-e0b5-2dd8b1072e49@codeaurora.org> References: <2a0d5719-b2c7-1287-e0b5-2dd8b1072e49@codeaurora.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: Approximate MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: neeraju@codeaurora.org, julien.thierry.kdev@gmail.com, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 07 May 2020 17:06:19 +0100, Neeraj Upadhyay wrote: > > Hi, > > I have one query regarding pseudo NMI support on GIC v3; from what I > could understand, GIC v3 supports pseudo NMI setup for SPIs and PPIs. > However the request_nmi() in irq framework requires NMI to be per cpu > interrupt source (it checks for IRQF_PERCPU). Can you please help > understand this part, how SPIs can be configured as NMIs, if there is > a per cpu interrupt source restriction? Let me answer your question by another question: what is the semantic of a NMI if you can't associate it with a particular CPU? We use pseudo-NMI to be able to profile (or detect lockups) within sections where normal interrupts cannot fire. If the interrupt can end-up on a random CPU (with an unrelated PMU or one that hasn't locked up), what have we achieved? Only confusion. The whole point is that NMIs have to be tied to a given CPU. For SGI/PPI, this is guaranteed by construction. For SPIs, this means that the affinity cannot be changed from userspace. IRQF_PERCPU doesn't mean much in this context as we don't "broadcast" interrupts, but is an indication to the core kernel that the same interrupt cannot be taken on another CPU. The short of it is that NMIs are only for per-CPU sources. For SPIs, that's for PMUs that use SPIs instead of PPIs. Don't use it for anything else. Thanks, M. -- Without deviation from the norm, progress is not possible.