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