[PATCH 0/3] MSHV intercepts support on arm64

[PATCH 0/3] MSHV intercepts support on arm64

[Anirudh Raybharam]

From: Anirudh Rayabharam <anirudh@anirudhrb.com>

To receive hypervisor intercept interrupts on arm64 under MSHV, the parent
partition must allocate an interrupt in the SGI or PPI range and program it
into the SYNIC. Currently, Linux provides no mechanism for drivers to
dynamically allocate either SGIs or PPIs. SGIs are allocated exclusively by
the GIC driver for use by the SMP subsystem as IPIs, while PPIs must be
described in firmware (DT or ACPI), leaving the OS unable to allocate new
ones at runtime.

This series introduces support for MSHV by extending the GICv3 driver to
reserve one additional SGI specifically for use by the MSHV driver. The
reserved SGI is then used by the MSHV driver to program the SYNIC and
receive hypervisor intercept notifications.

This mechanism allows the MSHV driver to function correctly on arm64
without requiring firmware changes or altering the semantics of PPIs, while
keeping the SGI allocation model self-contained within the GIC driver.

Anirudh Rayabharam (Microsoft) (3):
  arm64: hyperv: move hyperv detection earlier in boot
  irqchip/gic-v3: allocate one SGI for MSHV
  mshv: add support for VMEXIT interrupts on aarch64

 arch/arm64/hyperv/mshyperv.c      | 31 +++++++++++++---
 arch/arm64/include/asm/mshyperv.h | 10 ++++++
 arch/arm64/kernel/setup.c         |  6 ++++
 drivers/hv/mshv_root_main.c       | 59 +++++++++++++++++++++++++++++++
 drivers/hv/mshv_synic.c           | 15 ++++----
 drivers/irqchip/irq-gic-v3.c      | 29 +++++++++++++--
 include/asm-generic/mshyperv.h    |  3 ++
 7 files changed, 139 insertions(+), 14 deletions(-)

-- 
2.34.1

[PATCH 1/3] arm64: hyperv: move hyperv detection earlier in boot

[Anirudh Raybharam]

From: Anirudh Rayabharam <anirudh@anirudhrb.com>

From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>

Move hyperv detection earlier in the boot. The goal is to detect hyperv
and the type of partition we're running in before the GICv3 setup.

This will be used in the subsequent patches to allocate an SGI for use
by the hyperv subsystem.

Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
---
 arch/arm64/hyperv/mshyperv.c      | 18 ++++++++++++++----
 arch/arm64/include/asm/mshyperv.h |  2 ++
 arch/arm64/kernel/setup.c         |  6 ++++++
 3 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
index 4fdc26ade1d7..cc443a5d6c71 100644
--- a/arch/arm64/hyperv/mshyperv.c
+++ b/arch/arm64/hyperv/mshyperv.c
@@ -17,6 +17,7 @@
 #include <linux/cpuhotplug.h>
 #include <asm/mshyperv.h>
 
+static bool hyperv_detected;
 static bool hyperv_initialized;
 
 int hv_get_hypervisor_version(union hv_hypervisor_version_info *info)
@@ -70,20 +71,21 @@ static bool __init hyperv_detect_via_smccc(void)
 	return arm_smccc_hypervisor_has_uuid(&hyperv_uuid);
 }
 
-static int __init hyperv_init(void)
+void __init hyperv_early_init(void)
 {
 	struct hv_get_vp_registers_output	result;
 	u64	guest_id;
-	int	ret;
 
 	/*
 	 * Allow for a kernel built with CONFIG_HYPERV to be running in
 	 * a non-Hyper-V environment.
 	 *
-	 * In such cases, do nothing and return success.
+	 * In such cases, do nothing and return.
 	 */
 	if (!hyperv_detect_via_acpi() && !hyperv_detect_via_smccc())
-		return 0;
+		return;
+
+	hyperv_detected = true;
 
 	/* Setup the guest ID */
 	guest_id = hv_generate_guest_id(LINUX_VERSION_CODE);
@@ -103,6 +105,14 @@ static int __init hyperv_init(void)
 		ms_hyperv.misc_features);
 
 	hv_identify_partition_type();
+}
+
+static int __init hyperv_init(void)
+{
+	int	ret;
+
+	if (!hyperv_detected)
+		return 0;
 
 	ret = hv_common_init();
 	if (ret)
diff --git a/arch/arm64/include/asm/mshyperv.h b/arch/arm64/include/asm/mshyperv.h
index b721d3134ab6..58fde70c2e39 100644
--- a/arch/arm64/include/asm/mshyperv.h
+++ b/arch/arm64/include/asm/mshyperv.h
@@ -53,6 +53,8 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
 	return hv_get_msr(reg);
 }
 
+void hyperv_early_init(void);
+
 /* SMCCC hypercall parameters */
 #define HV_SMCCC_FUNC_NUMBER	1
 #define HV_FUNC_ID	ARM_SMCCC_CALL_VAL(			\
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 23c05dc7a8f2..eccf5f19da6b 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -54,6 +54,7 @@
 #include <asm/efi.h>
 #include <asm/xen/hypervisor.h>
 #include <asm/mmu_context.h>
+#include <asm/mshyperv.h>
 
 static int num_standard_resources;
 static struct resource *standard_resources;
@@ -354,6 +355,11 @@ void __init __no_sanitize_address setup_arch(char **cmdline_p)
 	else
 		psci_acpi_init();
 
+	/*
+	 * This must come after psci init since Hyper-V detection uses SMCCC
+	 */
+	hyperv_early_init();
+
 	arm64_rsi_init();
 
 	init_bootcpu_ops();
-- 
2.34.1

Re: [PATCH 1/3] arm64: hyperv: move hyperv detection earlier in boot

[kernel test robot]

Hi 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-2-anirudh%40anirudhrb.com
patch subject: [PATCH 1/3] arm64: hyperv: move hyperv detection earlier in boot
config: arm64-allnoconfig (https://download.01.org/0day-ci/archive/20251126/202511260546.RGx7vwyX-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 15.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251126/202511260546.RGx7vwyX-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/202511260546.RGx7vwyX-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from arch/arm64/include/asm/mshyperv.h:66,
                    from arch/arm64/kernel/setup.c:57:
>> include/asm-generic/mshyperv.h:326:38: error: return type is an incomplete type
     326 | static inline enum hv_isolation_type hv_get_isolation_type(void)
         |                                      ^~~~~~~~~~~~~~~~~~~~~
   include/asm-generic/mshyperv.h: In function 'hv_get_isolation_type':
>> include/asm-generic/mshyperv.h:328:16: error: 'HV_ISOLATION_TYPE_NONE' undeclared (first use in this function)
     328 |         return HV_ISOLATION_TYPE_NONE;
         |                ^~~~~~~~~~~~~~~~~~~~~~
   include/asm-generic/mshyperv.h:328:16: note: each undeclared identifier is reported only once for each function it appears in
>> include/asm-generic/mshyperv.h:328:16: error: 'return' with a value, in function returning void [-Wreturn-mismatch]
   include/asm-generic/mshyperv.h:326:38: note: declared here
     326 | static inline enum hv_isolation_type hv_get_isolation_type(void)
         |                                      ^~~~~~~~~~~~~~~~~~~~~


vim +326 include/asm-generic/mshyperv.h

7ad9bb9d0f357d Wei Liu                  2021-09-10  289  
3817854ba89201 Nuno Das Neves           2025-03-14  290  #define _hv_status_fmt(fmt) "%s: Hyper-V status: %#x = %s: " fmt
3817854ba89201 Nuno Das Neves           2025-03-14  291  #define hv_status_printk(level, status, fmt, ...) \
3817854ba89201 Nuno Das Neves           2025-03-14  292  do { \
3817854ba89201 Nuno Das Neves           2025-03-14  293  	u64 __status = (status); \
3817854ba89201 Nuno Das Neves           2025-03-14  294  	pr_##level(_hv_status_fmt(fmt), __func__, hv_result(__status), \
3817854ba89201 Nuno Das Neves           2025-03-14  295  		   hv_result_to_string(__status), ##__VA_ARGS__); \
3817854ba89201 Nuno Das Neves           2025-03-14  296  } while (0)
3817854ba89201 Nuno Das Neves           2025-03-14  297  #define hv_status_err(status, fmt, ...) \
3817854ba89201 Nuno Das Neves           2025-03-14  298  	hv_status_printk(err, status, fmt, ##__VA_ARGS__)
3817854ba89201 Nuno Das Neves           2025-03-14  299  #define hv_status_debug(status, fmt, ...) \
3817854ba89201 Nuno Das Neves           2025-03-14  300  	hv_status_printk(debug, status, fmt, ##__VA_ARGS__)
3817854ba89201 Nuno Das Neves           2025-03-14  301  
3817854ba89201 Nuno Das Neves           2025-03-14  302  const char *hv_result_to_string(u64 hv_status);
9d8731a1757bef Nuno Das Neves           2025-02-21  303  int hv_result_to_errno(u64 status);
f3a99e761efa61 Tianyu Lan               2020-04-06  304  void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die);
765e33f5211ab6 Michael Kelley           2019-05-30  305  bool hv_is_hyperv_initialized(void);
b96f86534fa310 Dexuan Cui               2019-11-19  306  bool hv_is_hibernation_supported(void);
a6c76bb08dc7f7 Andrea Parri (Microsoft  2021-02-01  307) enum hv_isolation_type hv_get_isolation_type(void);
a6c76bb08dc7f7 Andrea Parri (Microsoft  2021-02-01  308) bool hv_is_isolation_supported(void);
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25  309  bool hv_isolation_type_snp(void);
20c89a559e00df Tianyu Lan               2021-10-25  310  u64 hv_ghcb_hypercall(u64 control, void *input, void *output, u32 input_size);
d6e0228d265f29 Dexuan Cui               2023-08-24  311  u64 hv_tdx_hypercall(u64 control, u64 param1, u64 param2);
3e1b611515d286 Tianyu Lan               2025-09-18  312  void hv_enable_coco_interrupt(unsigned int cpu, unsigned int vector, bool set);
a156ad8c508209 Roman Kisel              2025-10-08  313  void hv_para_set_sint_proxy(bool enable);
e6eeb3c782739c Roman Kisel              2025-10-08  314  u64 hv_para_get_synic_register(unsigned int reg);
e6eeb3c782739c Roman Kisel              2025-10-08  315  void hv_para_set_synic_register(unsigned int reg, u64 val);
765e33f5211ab6 Michael Kelley           2019-05-30  316  void hyperv_cleanup(void);
6dc2a774cb4fdb Sunil Muthuswamy         2021-03-23  317  bool hv_query_ext_cap(u64 cap_query);
37200078ed6aa2 Michael Kelley           2022-03-24  318  void hv_setup_dma_ops(struct device *dev, bool coherent);
765e33f5211ab6 Michael Kelley           2019-05-30  319  #else /* CONFIG_HYPERV */
db912b8954c23a Nuno Das Neves           2025-02-21  320  static inline void hv_identify_partition_type(void) {}
765e33f5211ab6 Michael Kelley           2019-05-30  321  static inline bool hv_is_hyperv_initialized(void) { return false; }
b96f86534fa310 Dexuan Cui               2019-11-19  322  static inline bool hv_is_hibernation_supported(void) { return false; }
765e33f5211ab6 Michael Kelley           2019-05-30  323  static inline void hyperv_cleanup(void) {}
f2580a907e5c0e Michael Kelley           2024-03-18  324  static inline void ms_hyperv_late_init(void) {}
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25  325  static inline bool hv_is_isolation_supported(void) { return false; }
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25 @326  static inline enum hv_isolation_type hv_get_isolation_type(void)
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25  327  {
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25 @328  	return HV_ISOLATION_TYPE_NONE;
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25  329  }
765e33f5211ab6 Michael Kelley           2019-05-30  330  #endif /* CONFIG_HYPERV */
765e33f5211ab6 Michael Kelley           2019-05-30  331  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 1/3] arm64: hyperv: move hyperv detection earlier in boot

[kernel test robot]

Hi Anirudh,

kernel test robot noticed the following build warnings:

[auto build test WARNING on next-20251125]
[also build test WARNING 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-2-anirudh%40anirudhrb.com
patch subject: [PATCH 1/3] arm64: hyperv: move hyperv detection earlier in boot
config: arm64-randconfig-003-20251127 (https://download.01.org/0day-ci/archive/20251127/202511271709.lBS024jA-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 9.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251127/202511271709.lBS024jA-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/202511271709.lBS024jA-lkp@intel.com/

All warnings (new ones prefixed by >>):

   In file included from arch/arm64/include/asm/mshyperv.h:66,
                    from arch/arm64/kernel/setup.c:57:
   include/asm-generic/mshyperv.h:326:38: error: return type is an incomplete type
     326 | static inline enum hv_isolation_type hv_get_isolation_type(void)
         |                                      ^~~~~~~~~~~~~~~~~~~~~
   include/asm-generic/mshyperv.h: In function 'hv_get_isolation_type':
   include/asm-generic/mshyperv.h:328:9: error: 'HV_ISOLATION_TYPE_NONE' undeclared (first use in this function)
     328 |  return HV_ISOLATION_TYPE_NONE;
         |         ^~~~~~~~~~~~~~~~~~~~~~
   include/asm-generic/mshyperv.h:328:9: note: each undeclared identifier is reported only once for each function it appears in
>> include/asm-generic/mshyperv.h:328:9: warning: 'return' with a value, in function returning void [-Wreturn-type]
   include/asm-generic/mshyperv.h:326:38: note: declared here
     326 | static inline enum hv_isolation_type hv_get_isolation_type(void)
         |                                      ^~~~~~~~~~~~~~~~~~~~~


vim +/return +328 include/asm-generic/mshyperv.h

7ad9bb9d0f357d Wei Liu                  2021-09-10  289  
3817854ba89201 Nuno Das Neves           2025-03-14  290  #define _hv_status_fmt(fmt) "%s: Hyper-V status: %#x = %s: " fmt
3817854ba89201 Nuno Das Neves           2025-03-14  291  #define hv_status_printk(level, status, fmt, ...) \
3817854ba89201 Nuno Das Neves           2025-03-14  292  do { \
3817854ba89201 Nuno Das Neves           2025-03-14  293  	u64 __status = (status); \
3817854ba89201 Nuno Das Neves           2025-03-14  294  	pr_##level(_hv_status_fmt(fmt), __func__, hv_result(__status), \
3817854ba89201 Nuno Das Neves           2025-03-14  295  		   hv_result_to_string(__status), ##__VA_ARGS__); \
3817854ba89201 Nuno Das Neves           2025-03-14  296  } while (0)
3817854ba89201 Nuno Das Neves           2025-03-14  297  #define hv_status_err(status, fmt, ...) \
3817854ba89201 Nuno Das Neves           2025-03-14  298  	hv_status_printk(err, status, fmt, ##__VA_ARGS__)
3817854ba89201 Nuno Das Neves           2025-03-14  299  #define hv_status_debug(status, fmt, ...) \
3817854ba89201 Nuno Das Neves           2025-03-14  300  	hv_status_printk(debug, status, fmt, ##__VA_ARGS__)
3817854ba89201 Nuno Das Neves           2025-03-14  301  
3817854ba89201 Nuno Das Neves           2025-03-14  302  const char *hv_result_to_string(u64 hv_status);
9d8731a1757bef Nuno Das Neves           2025-02-21  303  int hv_result_to_errno(u64 status);
f3a99e761efa61 Tianyu Lan               2020-04-06  304  void hyperv_report_panic(struct pt_regs *regs, long err, bool in_die);
765e33f5211ab6 Michael Kelley           2019-05-30  305  bool hv_is_hyperv_initialized(void);
b96f86534fa310 Dexuan Cui               2019-11-19  306  bool hv_is_hibernation_supported(void);
a6c76bb08dc7f7 Andrea Parri (Microsoft  2021-02-01  307) enum hv_isolation_type hv_get_isolation_type(void);
a6c76bb08dc7f7 Andrea Parri (Microsoft  2021-02-01  308) bool hv_is_isolation_supported(void);
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25  309  bool hv_isolation_type_snp(void);
20c89a559e00df Tianyu Lan               2021-10-25  310  u64 hv_ghcb_hypercall(u64 control, void *input, void *output, u32 input_size);
d6e0228d265f29 Dexuan Cui               2023-08-24  311  u64 hv_tdx_hypercall(u64 control, u64 param1, u64 param2);
3e1b611515d286 Tianyu Lan               2025-09-18  312  void hv_enable_coco_interrupt(unsigned int cpu, unsigned int vector, bool set);
a156ad8c508209 Roman Kisel              2025-10-08  313  void hv_para_set_sint_proxy(bool enable);
e6eeb3c782739c Roman Kisel              2025-10-08  314  u64 hv_para_get_synic_register(unsigned int reg);
e6eeb3c782739c Roman Kisel              2025-10-08  315  void hv_para_set_synic_register(unsigned int reg, u64 val);
765e33f5211ab6 Michael Kelley           2019-05-30  316  void hyperv_cleanup(void);
6dc2a774cb4fdb Sunil Muthuswamy         2021-03-23  317  bool hv_query_ext_cap(u64 cap_query);
37200078ed6aa2 Michael Kelley           2022-03-24  318  void hv_setup_dma_ops(struct device *dev, bool coherent);
765e33f5211ab6 Michael Kelley           2019-05-30  319  #else /* CONFIG_HYPERV */
db912b8954c23a Nuno Das Neves           2025-02-21  320  static inline void hv_identify_partition_type(void) {}
765e33f5211ab6 Michael Kelley           2019-05-30  321  static inline bool hv_is_hyperv_initialized(void) { return false; }
b96f86534fa310 Dexuan Cui               2019-11-19  322  static inline bool hv_is_hibernation_supported(void) { return false; }
765e33f5211ab6 Michael Kelley           2019-05-30  323  static inline void hyperv_cleanup(void) {}
f2580a907e5c0e Michael Kelley           2024-03-18  324  static inline void ms_hyperv_late_init(void) {}
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25  325  static inline bool hv_is_isolation_supported(void) { return false; }
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25  326  static inline enum hv_isolation_type hv_get_isolation_type(void)
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25  327  {
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25 @328  	return HV_ISOLATION_TYPE_NONE;
0cc4f6d9f0b9f2 Tianyu Lan               2021-10-25  329  }
765e33f5211ab6 Michael Kelley           2019-05-30  330  #endif /* CONFIG_HYPERV */
765e33f5211ab6 Michael Kelley           2019-05-30  331  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Anirudh Raybharam]

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

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

[Marc Zyngier]

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.

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

[Anirudh Rayabharam]

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.

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

[Marc Zyngier]

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.

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

[Anirudh Rayabharam]

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.

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

[Marc Zyngier]

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.

Re: [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@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.

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

[Wei Liu]

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

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

[kernel test robot]

Hi 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

[PATCH 3/3] mshv: add support for VMEXIT interrupts on aarch64

[Anirudh Raybharam]

From: Anirudh Rayabharam <anirudh@anirudhrb.com>

From: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>

Use the SGI allocated for MSHV as the interrupt vector to get notified
of hypervisor intercepts.

Currently, HYPERVISOR_CALLBACK_VECTOR is hardcoded for this. This macro
exists only for x86. To make things generic, introduce an arch-specific
init function mshv_arch_parent_partition_init() which, for now, is
responsible for setting up the interception interrupt and writing it to
the mshv_interrupt global. mshv_interrupt is then used when programming
the SYNIC.

Co-developed-by: Jinank Jain <jinankjain@microsoft.com>
Signed-off-by: Jinank Jain <jinankjain@microsoft.com>
Signed-off-by: Anirudh Rayabharam (Microsoft) <anirudh@anirudhrb.com>
---
 drivers/hv/mshv_root_main.c    | 59 ++++++++++++++++++++++++++++++++++
 drivers/hv/mshv_synic.c        | 15 +++++----
 include/asm-generic/mshyperv.h |  3 ++
 3 files changed, 70 insertions(+), 7 deletions(-)

diff --git a/drivers/hv/mshv_root_main.c b/drivers/hv/mshv_root_main.c
index bc15d6f6922f..e48a89688ecb 100644
--- a/drivers/hv/mshv_root_main.c
+++ b/drivers/hv/mshv_root_main.c
@@ -17,7 +17,9 @@
 #include <linux/file.h>
 #include <linux/anon_inodes.h>
 #include <linux/mm.h>
+#include <linux/interrupt.h>
 #include <linux/io.h>
+#include <linux/irq.h>
 #include <linux/cpuhotplug.h>
 #include <linux/random.h>
 #include <asm/mshyperv.h>
@@ -75,6 +77,11 @@ static vm_fault_t mshv_vp_fault(struct vm_fault *vmf);
 static int mshv_init_async_handler(struct mshv_partition *partition);
 static void mshv_async_hvcall_handler(void *data, u64 *status);
 
+
+int mshv_interrupt = -1;
+int mshv_irq = -1;
+static long __percpu *mshv_evt;
+
 static const union hv_input_vtl input_vtl_zero;
 static const union hv_input_vtl input_vtl_normal = {
 	.target_vtl = HV_NORMAL_VTL,
@@ -2311,6 +2318,47 @@ static void mshv_init_vmm_caps(struct device *dev)
 	dev_dbg(dev, "vmm_caps = %#llx\n", mshv_root.vmm_caps.as_uint64[0]);
 }
 
+#if IS_ENABLED(CONFIG_ARM64)
+static irqreturn_t mshv_percpu_isr(int irq, void *dev_id)
+{
+	mshv_isr();
+	add_interrupt_randomness(irq);
+	return IRQ_HANDLED;
+}
+
+static int mshv_arch_parent_partition_init(struct device *dev)
+{
+	int ret;
+
+	mshv_irq = mshv_get_intercept_irq();
+	mshv_interrupt = irq_get_irq_data(mshv_irq)->hwirq;
+
+	mshv_evt = alloc_percpu(long);
+	if (!mshv_evt) {
+		dev_err(dev, "Failed to allocate percpu event\n");
+		return -ENOMEM;
+	}
+
+	ret = request_percpu_irq(mshv_irq, mshv_percpu_isr, "MSHV", mshv_evt);
+	if (ret) {
+		dev_err(dev, "Failed to request percpu irq\n");
+		goto free_percpu_buf;
+	}
+
+	return ret;
+
+free_percpu_buf:
+	free_percpu(mshv_evt);
+	return ret;
+}
+#elif IS_ENABLED(CONFIG_X86_64)
+static int mshv_arch_parent_partition_init(struct device *dev)
+{
+	mshv_interrupt = HYPERVISOR_CALLBACK_VECTOR;
+	return 0;
+}
+#endif
+
 static int __init mshv_parent_partition_init(void)
 {
 	int ret;
@@ -2329,6 +2377,10 @@ static int __init mshv_parent_partition_init(void)
 
 	dev = mshv_dev.this_device;
 
+	ret = mshv_arch_parent_partition_init(dev);
+	if (ret)
+		return ret;
+
 	if (version_info.build_number < MSHV_HV_MIN_VERSION ||
 	    version_info.build_number > MSHV_HV_MAX_VERSION) {
 		dev_err(dev, "Running on unvalidated Hyper-V version\n");
@@ -2396,6 +2448,13 @@ static void __exit mshv_parent_partition_exit(void)
 	mshv_irqfd_wq_cleanup();
 	if (hv_root_partition())
 		mshv_root_partition_exit();
+	if (mshv_irq >= 0) {
+		if (mshv_evt) {
+			free_percpu_irq(mshv_irq, mshv_evt);
+			free_percpu(mshv_evt);
+			mshv_evt = NULL;
+		}
+	}
 	cpuhp_remove_state(mshv_cpuhp_online);
 	free_percpu(mshv_root.synic_pages);
 }
diff --git a/drivers/hv/mshv_synic.c b/drivers/hv/mshv_synic.c
index f8b0337cdc82..3bdb798f8948 100644
--- a/drivers/hv/mshv_synic.c
+++ b/drivers/hv/mshv_synic.c
@@ -10,6 +10,7 @@
 #include <linux/kernel.h>
 #include <linux/slab.h>
 #include <linux/mm.h>
+#include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/random.h>
 #include <asm/mshyperv.h>
@@ -451,9 +452,7 @@ int mshv_synic_init(unsigned int cpu)
 	union hv_synic_simp simp;
 	union hv_synic_siefp siefp;
 	union hv_synic_sirbp sirbp;
-#ifdef HYPERVISOR_CALLBACK_VECTOR
 	union hv_synic_sint sint;
-#endif
 	union hv_synic_scontrol sctrl;
 	struct hv_synic_pages *spages = this_cpu_ptr(mshv_root.synic_pages);
 	struct hv_message_page **msg_page = &spages->hyp_synic_message_page;
@@ -496,10 +495,13 @@ int mshv_synic_init(unsigned int cpu)
 
 	hv_set_non_nested_msr(HV_MSR_SIRBP, sirbp.as_uint64);
 
-#ifdef HYPERVISOR_CALLBACK_VECTOR
+
+	if (mshv_irq > 0)
+		enable_percpu_irq(mshv_irq, 0);
+
 	/* Enable intercepts */
 	sint.as_uint64 = 0;
-	sint.vector = HYPERVISOR_CALLBACK_VECTOR;
+	sint.vector = mshv_interrupt;
 	sint.masked = false;
 	sint.auto_eoi = hv_recommend_using_aeoi();
 	hv_set_non_nested_msr(HV_MSR_SINT0 + HV_SYNIC_INTERCEPTION_SINT_INDEX,
@@ -507,13 +509,12 @@ int mshv_synic_init(unsigned int cpu)
 
 	/* Doorbell SINT */
 	sint.as_uint64 = 0;
-	sint.vector = HYPERVISOR_CALLBACK_VECTOR;
+	sint.vector = mshv_interrupt;
 	sint.masked = false;
-	sint.as_intercept = 1;
 	sint.auto_eoi = hv_recommend_using_aeoi();
+	sint.as_intercept = 1;
 	hv_set_non_nested_msr(HV_MSR_SINT0 + HV_SYNIC_DOORBELL_SINT_INDEX,
 			      sint.as_uint64);
-#endif
 
 	/* Enable global synic bit */
 	sctrl.as_uint64 = hv_get_non_nested_msr(HV_MSR_SCONTROL);
diff --git a/include/asm-generic/mshyperv.h b/include/asm-generic/mshyperv.h
index ecedab554c80..8e30347f7946 100644
--- a/include/asm-generic/mshyperv.h
+++ b/include/asm-generic/mshyperv.h
@@ -189,6 +189,9 @@ void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs));
 void hv_remove_crash_handler(void);
 void hv_setup_mshv_handler(void (*handler)(void));
 
+extern int mshv_interrupt;
+extern int mshv_irq;
+
 #if IS_ENABLED(CONFIG_HYPERV)
 /*
  * Hypervisor's notion of virtual processor ID is different from
-- 
2.34.1