From: Anirudh Rayabharam <anirudh@anirudhrb.com>
From: Anirudh Rayabharam (Microsoft) <anirudh@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.
Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
---
arch/arm64/hyperv/mshyperv.c | 13 +++++++++++++
arch/arm64/include/asm/mshyperv.h | 8 ++++++++
drivers/irqchip/irq-gic-v3.c | 29 ++++++++++++++++++++++++++---
3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index cc443a5d6c71..99690ae9b53f 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -20,6 +20,8 @@
static bool hyperv_detected;
static bool hyperv_initialized;
+static int mshv_intercept_irq;
+
int hv_get_hypervisor_version(union hv_hypervisor_version_info *info)
{
hv_get_vpreg_128(HV_REGISTER_HYPERVISOR_VERSION,
@@ -137,6 +139,17 @@ static int __init hyperv_init(void)
return 0;
}
+void __init mshv_set_intercept_irq(int irq)
+{
+ mshv_intercept_irq = irq;
+}
+
+int mshv_get_intercept_irq(void)
+{
+ return mshv_intercept_irq;
+}
+EXPORT_SYMBOL_GPL(mshv_get_intercept_irq);
+
early_initcall(hyperv_init);
bool hv_is_hyperv_initialized(void)
diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
index 58fde70c2e39..f3f6e82a9cb6 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -55,6 +55,14 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
void hyperv_early_init(void);
+#if IS_ENABLED(CONFIG_MSHV_ROOT)
+void mshv_set_intercept_irq(int irq);
+#else
+static inline void mshv_set_intercept_irq(int irq) {}
+#endif
+
+int mshv_get_intercept_irq(void);
+
/* SMCCC hypercall parameters */
#define HV_SMCCC_FUNC_NUMBER 1
#define HV_FUNC_ID ARM_SMCCC_CALL_VAL( \
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 3de351e66ee8..56013dd0564c 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -35,6 +35,7 @@
#include <asm/exception.h>
#include <asm/smp_plat.h>
#include <asm/virt.h>
+#include <asm/mshyperv.h>
#include "irq-gic-common.h"
@@ -1456,8 +1457,24 @@ static void __init gic_smp_init(void)
.fwnode = gic_data.fwnode,
.param_count = 1,
};
+ /* Register all 8 non-secure SGIs */
+ const int NR_SMP_SGIS = 8;
+ int nr_sgis = NR_SMP_SGIS;
int base_sgi;
+ /*
+ * Allocate one more SGI for use by Hyper-V. This is only needed when
+ * Linux is running in a parent partition. Hyper-V will use this interrupt
+ * to notify the parent partition of intercepts.
+ *
+ * When running on Hyper-V, it is okay to use SGIs 8-15. They're not reserved
+ * for secure firmware.
+ */
+#if IS_ENABLED(CONFIG_HYPERV)
+ if (hv_parent_partition())
+ nr_sgis += 1;
+#endif
+
cpuhp_setup_state_nocalls(CPUHP_BP_PREPARE_DYN,
"irqchip/arm/gicv3:checkrdist",
gic_check_rdist, NULL);
@@ -1466,12 +1483,18 @@ static void __init gic_smp_init(void)
"irqchip/arm/gicv3:starting",
gic_starting_cpu, NULL);
- /* Register all 8 non-secure SGIs */
- base_sgi = irq_domain_alloc_irqs(gic_data.domain, 8, NUMA_NO_NODE, &sgi_fwspec);
+ base_sgi = irq_domain_alloc_irqs(gic_data.domain, nr_sgis, NUMA_NO_NODE, &sgi_fwspec);
if (WARN_ON(base_sgi <= 0))
return;
- set_smp_ipi_range(base_sgi, 8);
+ set_smp_ipi_range(base_sgi, NR_SMP_SGIS);
+
+#if IS_ENABLED(CONFIG_HYPERV)
+ if (hv_parent_partition()) {
+ base_sgi += NR_SMP_SGIS;
+ mshv_set_intercept_irq(base_sgi);
+ }
+#endif
}
static int gic_set_affinity(struct irq_data *d, const struct cpumask *mask_val,
--
2.34.1Hi Anirudh,
kernel test robot noticed the following build errors:
[auto build test ERROR on next-20251125]
[also build test ERROR on v6.18-rc7]
[cannot apply to arm64/for-next/core tip/irq/core arnd-asm-generic/master linus/master v6.18-rc7 v6.18-rc6 v6.18-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Anirudh-Raybharam/arm64-hyperv-move-hyperv-detection-earlier-in-boot/20251126-011057
base: next-20251125
patch link: https://lore.kernel.org/r/20251125170124.2443340-3-anirudh%40anirudhrb.com
patch subject: [PATCH 2/3] irqchip/gic-v3: allocate one SGI for MSHV
config: arm-randconfig-002-20251127 (https://download.01.org/0day-ci/archive/20251127/202511271745.71G6M2De-lkp@intel.com/config)
compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project b3428bb966f1de8aa48375ffee0eba04ede133b7)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251127/202511271745.71G6M2De-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202511271745.71G6M2De-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/irqchip/irq-gic-v3.c:37:10: fatal error: 'asm/mshyperv.h' file not found
37 | #include <asm/mshyperv.h>
| ^~~~~~~~~~~~~~~~
1 error generated.
vim +37 drivers/irqchip/irq-gic-v3.c
32
33 #include <asm/cputype.h>
34 #include <asm/exception.h>
35 #include <asm/smp_plat.h>
36 #include <asm/virt.h>
> 37 #include <asm/mshyperv.h>
38
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
On Tue, Nov 25, 2025 at 05:01:23PM +0000, Anirudh Raybharam wrote: > From: Anirudh Rayabharam <anirudh@anirudhrb.com> [...] > /* SMCCC hypercall parameters */ > #define HV_SMCCC_FUNC_NUMBER 1 > #define HV_FUNC_ID ARM_SMCCC_CALL_VAL( \ > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index 3de351e66ee8..56013dd0564c 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -35,6 +35,7 @@ > #include <asm/exception.h> > #include <asm/smp_plat.h> > #include <asm/virt.h> > +#include <asm/mshyperv.h> > > #include "irq-gic-common.h" > > @@ -1456,8 +1457,24 @@ static void __init gic_smp_init(void) > .fwnode = gic_data.fwnode, > .param_count = 1, > }; > + /* Register all 8 non-secure SGIs */ > + const int NR_SMP_SGIS = 8; > + int nr_sgis = NR_SMP_SGIS; > int base_sgi; > > + /* > + * Allocate one more SGI for use by Hyper-V. This is only needed when > + * Linux is running in a parent partition. Hyper-V will use this interrupt > + * to notify the parent partition of intercepts. > + * > + * When running on Hyper-V, it is okay to use SGIs 8-15. They're not reserved > + * for secure firmware. > + */ > +#if IS_ENABLED(CONFIG_HYPERV) > + if (hv_parent_partition()) > + nr_sgis += 1; > +#endif > + This is far too intrusive. Let's take Marc's feedback and work with the hypervisor team to resolve this properly. Wei
On Tue, 25 Nov 2025 17:01:23 +0000, Anirudh Raybharam <anirudh@anirudhrb.com> wrote: > > From: Anirudh Rayabharam <anirudh@anirudhrb.com> > > From: Anirudh Rayabharam (Microsoft) <anirudh@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 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. 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. Thanks, M. -- Without deviation from the norm, progress is not possible.
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@anirudhrb.com> wrote: > > > > From: Anirudh Rayabharam <anirudh@anirudhrb.com> > > > > From: Anirudh Rayabharam (Microsoft) <anirudh@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.
On Wed, 26 Nov 2025 08:51:59 +0000, Anirudh Rayabharam <anirudh@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@anirudhrb.com> wrote: > > > > > > From: Anirudh Rayabharam <anirudh@anirudhrb.com> > > > > > > From: Anirudh Rayabharam (Microsoft) <anirudh@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 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. > > > > 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? M. -- Without deviation from the norm, progress is not possible.
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@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@anirudhrb.com> wrote: > > > > > > > > From: Anirudh Rayabharam <anirudh@anirudhrb.com> > > > > > > > > From: Anirudh Rayabharam (Microsoft) <anirudh@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. 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? > > > > 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. > > > > > > > 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? Thanks, Anirudh. > > M. > > -- > Without deviation from the norm, progress is not possible.
On Wed, 26 Nov 2025 10:46:31 +0000, Anirudh Rayabharam <anirudh@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@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@anirudhrb.com> wrote: > > > > > > > > > > From: Anirudh Rayabharam <anirudh@anirudhrb.com> > > > > > > > > > > From: Anirudh Rayabharam (Microsoft) <anirudh@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). 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.
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@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@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@anirudhrb.com> wrote: > > > > > > > > > > > > From: Anirudh Rayabharam <anirudh@anirudhrb.com> > > > > > > > > > > > > From: Anirudh Rayabharam (Microsoft) <anirudh@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.
© 2016 - 2025 Red Hat, Inc.