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 87023C001DB for ; Mon, 7 Aug 2023 15:25:26 +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:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gaAxzSPBHVo5vi32vORNwySF/hCwnCsmvCDf/dl918g=; b=lkXBenZXgSP9l7 aJIORqjS4zafm73B+/r7AKujIxVjH+aYvB7cRyScIQmZymh2mdKp6F4bLP4NGvYcQduIshPyHFxsU D8SDz2pj7YeWYVUQuqMPI/9bo8cEb9grGoBbv4VY0BUOyGicHaRYdIbq6nE+kCWQAVAYgPot1JUK4 KYaDI2GfchxwzS/U9rbXaXX8k+VzRDeAlFdYwrcFg1k74QlUbhiKVOMLGq+8ThbjJIVlmCcVNbpK7 yUfd8SY25OKA4I07Ch0w4Xr7Bz2VKw4DvGTPAdRXnuUyieoB9JiIak697inDsa/3U4IZLCx4hgXfo v0Mt1keltegce8GHWL2w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qT26L-0002yh-1q; Mon, 07 Aug 2023 15:24:57 +0000 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qT26H-0002xA-2U for linux-arm-kernel@lists.infradead.org; Mon, 07 Aug 2023 15:24:55 +0000 Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-3fe24dd8898so40037415e9.2 for ; Mon, 07 Aug 2023 08:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1691421887; x=1692026687; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=RM6FEX0hkfSucEN2RNtPwB4Lp3pZ1/g2aHa0yo5DkxA=; b=YBfAYrox4WwNmSljlKByV5/fpIap2pKUoRw5AygT2uJb2iRFmdXouQKc9P8DlghNBn mD9d5xOsnCzGOCCwXphMo4cvJTfBp37FlIxYd5iaS6JX3YNY8Twb6NyyioxxNZ15/yMp OSRbBgvU2b1TwsfAaUxBxc0GDJJVxRUZBJGGmT1PN5bkFh/gdOovIuFoP+21R5ocXzBg 08QaWeNi1GpA9zhcYxWWOxOey3tkERo9fB23ax/OV6UI6IthFUHlfSILQ/SAuJhjxObI fj2F3r7m3cuIP6OxAgL66LQ1cbbrbBujYRezedh9b96POwP/ifMXwFnGRbeU4lgxz2j5 2RGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691421887; x=1692026687; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=RM6FEX0hkfSucEN2RNtPwB4Lp3pZ1/g2aHa0yo5DkxA=; b=UiPBAUveU3kyrmQk59wNe6h2uOgI4YaSa/wt9iLq4vKg0f3feVDmHhSSFw7i0S5GSE nZRA0B7Skwr4kR/6NDOcdYWJ/Ha3zJ9C//2k1cvYn4th0sYnXOYmzVhHZuJxT+AwHzA0 U1P/NID4ec+bO8qE269vO1VsN0caEK4YxvCmPbwFzEtbcZ31wo7dMYBGPeXwbZxgSHzQ IUoweN7WRQurgWBDJNrAlIzk2QCipzE0rCdr4lBOUSBnj+ZsL39DEMjD/LR59otG9tIU hF/t4s6roEdhSqzQs2mF7fSEA1vJBsTJyO/rsk4Y/xuCU+cNbtw9tjTKWNo5uB85zE6g ql+Q== X-Gm-Message-State: AOJu0Yw3R04ujy6Nl6Q3tHGIyfRACkPqihdcMmLGseUg1qbAsDpZSt10 y4cKErD7wRdqfXQ+dpcJ9NlwJA== X-Google-Smtp-Source: AGHT+IGBcN8x+jcr5Z6fXcbJpNL+hygXsHQl0A6iUvy8eoqLQSJBGrRviYCA1pNQ7vzL2NtQD5wOPw== X-Received: by 2002:a05:600c:2210:b0:3fb:a62d:1992 with SMTP id z16-20020a05600c221000b003fba62d1992mr6230198wml.0.1691421887335; Mon, 07 Aug 2023 08:24:47 -0700 (PDT) Received: from aspen.lan (aztw-34-b2-v4wan-166919-cust780.vm26.cable.virginm.net. [82.37.195.13]) by smtp.gmail.com with ESMTPSA id 4-20020a05600c248400b003fbb5506e54sm11026994wms.29.2023.08.07.08.24.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Aug 2023 08:24:46 -0700 (PDT) Date: Mon, 7 Aug 2023 16:24:44 +0100 From: Daniel Thompson To: Mark Rutland Cc: Douglas Anderson , Catalin Marinas , Will Deacon , Sumit Garg , Marc Zyngier , linux-perf-users@vger.kernel.org, ito-yuichi@fujitsu.com, Chen-Yu Tsai , Ard Biesheuvel , Stephen Boyd , Peter Zijlstra , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, kgdb-bugreport@lists.sourceforge.net, Masayoshi Mizuma , "Rafael J . Wysocki" , Lecopzer Chen , Wei Li , linux-kernel@vger.kernel.org Subject: Re: [PATCH v9 7/7] arm64: kgdb: Roundup cpus using the debug IPI Message-ID: <20230807152444.GA375529@aspen.lan> References: <20230601213440.2488667-1-dianders@chromium.org> <20230601143109.v9.7.I2ef26d1b3bfbed2d10a281942b0da7d9854de05e@changeid> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230807_082453_813786_152E0F0E X-CRM114-Status: GOOD ( 24.11 ) 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 Mon, Aug 07, 2023 at 11:28:52AM +0100, Mark Rutland wrote: > On Thu, Jun 01, 2023 at 02:31:51PM -0700, Douglas Anderson wrote: > > From: Sumit Garg > > > > Let's use the debug IPI for rounding up CPUs in kgdb. When the debug > > IPI is backed by an NMI (or pseudo NMI) then this will let us debug > > even hard locked CPUs. When the debug IPI isn't backed by an NMI then > > this won't really have any huge benefit but it will still work. > > > > Signed-off-by: Sumit Garg > > Signed-off-by: Douglas Anderson > > --- > > > > Changes in v9: > > - Remove fallback for when debug IPI isn't available. > > - Renamed "NMI IPI" to "debug IPI" since it might not be backed by NMI. > > > > arch/arm64/kernel/ipi_debug.c | 5 +++++ > > arch/arm64/kernel/kgdb.c | 14 ++++++++++++++ > > 2 files changed, 19 insertions(+) > > This looks fine to me, but I'd feel a bit happier if we had separate SGIs for > the backtrace and the KGDB callback as they're logically unrelated. I've no objections to seperate SGIs (if one can be found) but I'm curious what benefit emerges from giving them seperate IPIs. Both interfaces are already designed to share and NMI-like IPI nicely (and IIUC they must share one on x86), neither is performance critical[1] and the content of /proc/interrupts for the IPI is seldom going to be of much interest. As mentioned it is perfectly OK to separate them if there is space in the SGI allocations. However if any two functions are good candidates to share a scarce resource such as an SGI then it is these! Daniel. [1] In both cases their results are only required at human-scale and the work of the both handlers is hugely more expensive than either up front quick-check. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel