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 C9A59D111A2 for ; Wed, 26 Nov 2025 21:27:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=o9tue26DQxO++HXVs02pyq6EWYiqrHxraR4WKyqzNvM=; b=VeXbYyBsbAOvyqRcOQ78JCqKV3 bfVWoXu8fWwIfZ5uIKK8/TAF6LiwndddHpgFU99Dv6TUDWy75GxkY23U9S8x3tGIszRxB8/lqbLyk WiJQxAxtHXSYuHXQHoL2uUtqhRgE4rWxRKE2suiO8NEO2wESYu0i1w+lhjAAA1PmmrWtALYYRNg3k iBJ/wjZ48MjEL3h4hq9Ut+leiqpnnmR9Rdu6qNL+vhHCImjRg8YSwherFdH9tqQ9dGaOZ1T/oplA2 XghYRXn2v/LrsoqA3RxPEYpj+DKwxfLA++YPsIxRPjjr1gUk0GpBg2X7pIrTNkAeeMdchHaCM9uFn pvMg3RLA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vON2n-0000000FfSx-3nmP; Wed, 26 Nov 2025 21:27:21 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vON2l-0000000FfSc-26PJ for linux-arm-kernel@lists.infradead.org; Wed, 26 Nov 2025 21:27:20 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id C9629434C7; Wed, 26 Nov 2025 21:27:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9EF23C4CEF7; Wed, 26 Nov 2025 21:27:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764192438; bh=UQnLWxc/wM1eSVgZ7FgjAB7Jt2Jd2XH4TEEk2eldkFE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oanYzg0+6qQ6bkc5msMLK23EZpc5t7l3oAAM0cDZap+sXWaFe6qamvPE3j7NAWahy v5GaDqN0z8F9SL3BZWpCHx+siUz3P41tyRsMTRCmSmT44bPSrWGPAC4lOxeOK/T/Fw JNyqaKR5CWbGDhvnGsR33e81HTibzU9xvH7K+5/dVKw2DyAWsYnuzHGc8pnJYpYI1m Pnklm7wqgie49eoz7UxUBldhzW1xfRslCt+3XSAckF9hrXNY8JaqrHS8dOzGSNQ1SW 3iiC3J5aaZbnti0Xe5Yzr8kmJs8FhExih/A2TAKKR3YHnWyf33OnzwtWEKIKd+uOHJ HmyBMZRYhkrQQ== Received: from sofa.misterjones.org ([185.219.108.64] helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vON2i-00000008c68-0hch; Wed, 26 Nov 2025 21:27:16 +0000 Date: Wed, 26 Nov 2025 21:27:15 +0000 Message-ID: <87bjkofpsc.wl-maz@kernel.org> From: Marc Zyngier To: Anirudh Rayabharam Cc: kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com, catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de, Arnd Bergmann , akpm@linux-foundation.org, agordeev@linux.ibm.com, guoweikang.kernel@gmail.com, osandov@fb.com, bsz@amazon.de, linux-hyperv@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: [PATCH 2/3] irqchip/gic-v3: allocate one SGI for MSHV In-Reply-To: References: <20251125170124.2443340-1-anirudh@anirudhrb.com> <20251125170124.2443340-3-anirudh@anirudhrb.com> <86bjkqq9dp.wl-maz@kernel.org> <86a509qi8p.wl-maz@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/30.1 (aarch64-unknown-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: anirudh@anirudhrb.com, kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com, longli@microsoft.com, catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de, arnd@arndb.de, akpm@linux-foundation.org, agordeev@linux.ibm.com, guoweikang.kernel@gmail.com, osandov@fb.com, bsz@amazon.de, linux-hyperv@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251126_132719_606559_F8136D5E X-CRM114-Status: GOOD ( 47.89 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 26 Nov 2025 10:46:31 +0000, Anirudh Rayabharam wrote: > > On Wed, Nov 26, 2025 at 09:02:30AM +0000, Marc Zyngier wrote: > > On Wed, 26 Nov 2025 08:51:59 +0000, > > Anirudh Rayabharam wrote: > > > > > > On Tue, Nov 25, 2025 at 06:01:38PM +0000, Marc Zyngier wrote: > > > > On Tue, 25 Nov 2025 17:01:23 +0000, > > > > Anirudh Raybharam wrote: > > > > > > > > > > From: Anirudh Rayabharam > > > > > > > > > > From: Anirudh Rayabharam (Microsoft) > > > > > > > > > > Currently SGIs are allocated only for the smp subsystem. The MSHV > > > > > (Microsoft Hypervisor aka Hyper-V) code also needs an SGI that can be > > > > > programmed into the SYNIC to receive intercepts from the hypervisor. The > > > > > hypervisor would then assert this SGI whenever there is a guest > > > > > VMEXIT. > > > > > > > > > > Allocate one SGI for MSHV use in addition to the SGIs allocated for > > > > > IPIs. When running under MSHV, the full SGI range can be used i.e. no > > > > > need to reserve SGIs 8-15 for the secure firmware. > > > > > > > > > > Since this SGI is needed only when running as a parent partition (i.e. > > > > > we can create guest partitions), check for it before allocating an SGI. > > > > > > > > Sorry, but that's not an acceptable situation. > > > > > > > > SGIs are for Linux to use, nobody else, and that allocation must be > > > > > > Why does this restriction exist? In the code SGIs 8-15 are left for > > > secure firmware. So, things other than Linux can use SGIs. Why not MSHV > > > then? > > > > Because SGIs are for *internal* usage. Not usage from another random > > piece of SW. The ACPI tables explicitly don't describe SGIs. DT > > explicitly don't describe SGIs. Do you get the clue? > > The name Software Generated Interrupts suggests that it is supposed to be > used by pieces of SW. I'm so glad you spell it out for me, I had no idea. I can't help but notice that it is not called SGIFRPOSIDKA (Software Generated Interrupt From Random Piece Of Software I Don't Know About). Linux owns the SGIs, full stop. If you want to generate interrupts from outside of Linux, use a standard interrupts. Not rocket science. > Yes, ACPI/DT don't describe SGIs because they're not supposed to be used > by devices. SW has full control over SGIs and it is up to the SW to > assign meaning to them, isn't it? No. It means that a single *consistent* software agent *owns* these interrupts and doesn't have to let *anyone* else use them from outer space. > > > > the same irrespective of whether Linux runs virtualised or not. This > > > > also won't work with GICv5 (there are no SGIs at all), so this is > > > > doomed from the very start, and would immediately create technical > > > > debt. > > > > > > Hyper-V always presents a GICv3 so we don't need to worry about GICv5. > > > > Well, that's pretty short sighted of you, and eventually you'll have > > to support it, or just die. So do the right thing from the beginning. > > Well, we don't when or if that will happen. But if it does happen, we > can solve it in a way that makes sense for GICv5. If there are no SGIs > at all, great, maybe we'll have a nicer solution then. Great. See you then. In the meantime, I have no interest in this sort of sorry hacks polluting the stuff I maintain. > > > > If you want to signal an interrupt to Linux, expose a device with an > > > > interrupt in a firmware table (i.e. not an SGI), and use that in your > > > > driver. > > > > > > You mean in the ACPI tables? That would require us to modify the > > > firmware to expose this virtual device right? > > > > Yes. How is that surprising? > > It's not ideal that we would need some custom firmware to run Linux on > MSHV (as a parent). Do you think there could be some other possible solution > for handling this in the kernel? Maybe by thinking of it as a platform specific > quirk or something? You either do it the *correct* way, by exposing a virtual device, with an edge-triggered PPI, just like other hypervisors have done, or you keep your toy to yourself. It is that simple. We don't have to accept ugly crap in Linux just for the sake of you not having to do the right thing in your firmware. Feel free to post a new series once you have something that matches the above expectations. M. -- Jazz isn't dead. It just smells funny.