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

Anirudh Rayabharam anirudh at anirudhrb.com
Wed Nov 26 00:51:59 PST 2025


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?

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

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

Anirudh.

> 
> Thanks,
> 
> 	M.
> 
> -- 
> Without deviation from the norm, progress is not possible.



More information about the linux-arm-kernel mailing list