[PATCH] x86/hyperv: reserve more vectors

[PATCH] x86/hyperv: reserve more vectors

[wei.liu]

From: Wei Liu <wei.liu@kernel.org>

Microsoft Hypervisor delivers three vectors to the NT HAL running in the
root partition and refuses to map a device interrupt to any of them when
interrupt remapping is not available in the system. As of writing, the
nested MSHV setup has no interrupt remapping capability.

The three vectors are:

  HAL_NT_APC_VECTOR		0x1F
  HAL_NT_DPC_VECTOR		0x2F
  HAL_NT_CLOCK_IPI_VECTOR	0xD2

0x1F is below FIRST_EXTERNAL_VECTOR so the vector allocator never hands
it out, but 0x2F and 0xD2 are both inside the allocatable range and are
handed out once enough vectors are in use. Mapping such an interrupt
then fails with HV_STATUS_INVALID_PARAMETER, and the interrupt is never
delivered.

Reserve all three next to the hypervisor debug vectors that are already
kept out of the allocator's hands.

Signed-off-by: Wei Liu <wei.liu@kernel.org>
---
 arch/x86/kernel/cpu/mshyperv.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 185d4f677ec0..229c7377a980 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -502,17 +502,32 @@ static void hv_reserve_irq_vectors(void)
 	#define HYPERV_DBG_ASSERT_VECTOR	0x2C
 	#define HYPERV_DBG_SERVICE_VECTOR	0x2D
 
+	/*
+	 * The hypervisor delivers these three to the NT HAL and refuses to
+	 * map a device interrupt to any of them.
+	 *
+	 * The hypervisor will provide a hint in the future when these
+	 * vectors become available to use.
+	 */
+	#define HAL_NT_APC_VECTOR		0x1F
+	#define HAL_NT_DPC_VECTOR		0x2F
+	#define HAL_NT_CLOCK_IPI_VECTOR		0xD2
+
 	if (cpu_feature_enabled(X86_FEATURE_FRED))
 		return;
 
 	if (test_and_set_bit(HYPERV_DBG_ASSERT_VECTOR, system_vectors) ||
 	    test_and_set_bit(HYPERV_DBG_SERVICE_VECTOR, system_vectors) ||
-	    test_and_set_bit(HYPERV_DBG_FASTFAIL_VECTOR, system_vectors))
+	    test_and_set_bit(HYPERV_DBG_FASTFAIL_VECTOR, system_vectors) ||
+	    test_and_set_bit(HAL_NT_APC_VECTOR, system_vectors) ||
+	    test_and_set_bit(HAL_NT_DPC_VECTOR, system_vectors) ||
+	    test_and_set_bit(HAL_NT_CLOCK_IPI_VECTOR, system_vectors))
 		BUG();
 
-	pr_info("Hyper-V: reserve vectors: 0x%x 0x%x 0x%x\n",
+	pr_info("Hyper-V: reserve vectors: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x\n",
 		HYPERV_DBG_ASSERT_VECTOR, HYPERV_DBG_SERVICE_VECTOR,
-		HYPERV_DBG_FASTFAIL_VECTOR);
+		HYPERV_DBG_FASTFAIL_VECTOR, HAL_NT_APC_VECTOR,
+		HAL_NT_DPC_VECTOR, HAL_NT_CLOCK_IPI_VECTOR);
 }
 
 static void __init ms_hyperv_init_platform(void)
-- 
2.53.0

Re: [PATCH] x86/hyperv: reserve more vectors

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch fails to resolve the interrupt mapping failure on systems with X86_FEATURE_FRED enabled because an early return bypasses the newly added vector reservations.
--

--- Patch [1]: [PATCH] x86/hyperv: reserve more vectors ---
commit b0d2bc1fc2c7327b5574f796990f799e59f429b9
Author: Wei Liu <wei.liu@kernel.org>

x86/hyperv: reserve more vectors

This commit reserves three additional vectors used by the Microsoft
Hypervisor to prevent the kernel vector allocator from mapping device
interrupts to them when interrupt remapping is unavailable.

> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -502,17 +502,32 @@ static void hv_reserve_irq_vectors(void)
[ ... ]
>  	if (cpu_feature_enabled(X86_FEATURE_FRED))
>  		return;
>  
>  	if (test_and_set_bit(HYPERV_DBG_ASSERT_VECTOR, system_vectors) ||
>  	    test_and_set_bit(HYPERV_DBG_SERVICE_VECTOR, system_vectors) ||
> -	    test_and_set_bit(HYPERV_DBG_FASTFAIL_VECTOR, system_vectors))
> +	    test_and_set_bit(HYPERV_DBG_FASTFAIL_VECTOR, system_vectors) ||
> +	    test_and_set_bit(HAL_NT_APC_VECTOR, system_vectors) ||
> +	    test_and_set_bit(HAL_NT_DPC_VECTOR, system_vectors) ||
> +	    test_and_set_bit(HAL_NT_CLOCK_IPI_VECTOR, system_vectors))
>  		BUG();

[Severity: High]
This is a pre-existing issue, but does placing these new vector reservations
after the FRED early return cause them to be bypassed on FRED-enabled
hardware?

Since the early return skips updating the system_vectors bitmap, vectors
0x2F and 0xD2 won't be reserved when X86_FEATURE_FRED is enabled.

Because the kernel's dynamic vector allocator still relies on the
system_vectors bitmap to avoid assigning device interrupts, won't the
allocator still hand these vectors out to drivers on FRED-enabled systems
and reproduce the mapping failure?

> -	pr_info("Hyper-V: reserve vectors: 0x%x 0x%x 0x%x\n",
> +	pr_info("Hyper-V: reserve vectors: 0x%x 0x%x 0x%x 0x%x 0x%x 0x%x\n",
>  		HYPERV_DBG_ASSERT_VECTOR, HYPERV_DBG_SERVICE_VECTOR,
> -		HYPERV_DBG_FASTFAIL_VECTOR);
> +		HYPERV_DBG_FASTFAIL_VECTOR, HAL_NT_APC_VECTOR,
> +		HAL_NT_DPC_VECTOR, HAL_NT_CLOCK_IPI_VECTOR);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260730005020.2181875-1-wei.liu@kernel.org?part=1