[PATCH 2/3] irqchip/gic-v3: allocate one SGI for MSHV

[Anirudh Rayabharam]

On Wed, Nov 26, 2025 at 09:27:15PM +0000, Marc Zyngier wrote:
> On Wed, 26 Nov 2025 10:46:31 +0000,
> Anirudh Rayabharam <anirudh at anirudhrb.com> 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 <anirudh at anirudhrb.com> 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 <anirudh at anirudhrb.com> wrote:
> > > > > > 
> > > > > > From: Anirudh Rayabharam <anirudh at anirudhrb.com>
> > > > > > 
> > > > > > From: Anirudh Rayabharam (Microsoft) <anirudh at anirudhrb.com>
> > > > > > 
> > > > > > 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).

Haha.

> 
> 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.

Okay, got it.

> 
> > > > > 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.

Okay got it, I'll come up with a series that reads PPIs from ACPI.

Thanks for your feedback!

Anirudh.

> 
> 	M.
> 
> -- 
> Jazz isn't dead. It just smells funny.