[RFC][PATCH v0] x86/hyperv: Reserve 3 interrupt vectors used exclusively by mshv

[RFC][PATCH v0] x86/hyperv: Reserve 3 interrupt vectors used exclusively by mshv

[Mukesh Rathor]

MSVC compiler used to compile the Microsoft Hyper-V hypervisor currently,
has an assert intrinsic that uses interrupt vector 0x29 to create an
exception. This will cause hypervisor to then crash and collect core. As
such, if this interrupt number is assigned to a device by linux and the
device generates it, hypervisor will crash. There are two other such
vectors hard coded in the hypervisor, 0x2C and 0x2D. 

Fortunately, the three vectors are part of the kernel driver space, and
that makes it feasible to reserve them early so they are not assigned
later.

Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
---
 arch/x86/kernel/cpu/mshyperv.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 579fb2c64cfd..19d41f7434df 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -478,6 +478,25 @@ int hv_get_hypervisor_version(union hv_hypervisor_version_info *info)
 }
 EXPORT_SYMBOL_GPL(hv_get_hypervisor_version);
 
+/*
+ * Reserve vectors hard coded in the hypervisor. If used outside, the hypervisor
+ * will crash or hang or break into debugger.
+ */
+static void hv_reserve_irq_vectors(void)
+{
+	#define HYPERV_DBG_FASTFAIL_VECTOR	0x29
+	#define HYPERV_DBG_ASSERT_VECTOR	0x2C
+	#define HYPERV_DBG_SERVICE_VECTOR	0x2D
+
+	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))
+		BUG();
+
+	pr_info("Hyper-V:reserve vectors: %d %d %d\n", HYPERV_DBG_ASSERT_VECTOR,
+		HYPERV_DBG_SERVICE_VECTOR, HYPERV_DBG_FASTFAIL_VECTOR);
+}
+
 static void __init ms_hyperv_init_platform(void)
 {
 	int hv_max_functions_eax, eax;
@@ -510,6 +529,9 @@ static void __init ms_hyperv_init_platform(void)
 
 	hv_identify_partition_type();
 
+	if (hv_root_partition())
+		hv_reserve_irq_vectors();
+
 	if (cc_platform_has(CC_ATTR_SNP_SECURE_AVIC))
 		ms_hyperv.hints |= HV_DEPRECATING_AEOI_RECOMMENDED;
 
-- 
2.51.2.vfs.0.1

Re: [RFC][PATCH v0] x86/hyperv: Reserve 3 interrupt vectors used exclusively by mshv

[Vitaly Kuznetsov]

Mukesh Rathor <mrathor@linux.microsoft.com> writes:

> MSVC compiler used to compile the Microsoft Hyper-V hypervisor currently,
> has an assert intrinsic that uses interrupt vector 0x29 to create an
> exception. This will cause hypervisor to then crash and collect core. As
> such, if this interrupt number is assigned to a device by linux and the
> device generates it, hypervisor will crash. There are two other such
> vectors hard coded in the hypervisor, 0x2C and 0x2D. 
>
> Fortunately, the three vectors are part of the kernel driver space, and
> that makes it feasible to reserve them early so they are not assigned
> later.
>
> Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
> ---
>  arch/x86/kernel/cpu/mshyperv.c | 22 ++++++++++++++++++++++
>  1 file changed, 22 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index 579fb2c64cfd..19d41f7434df 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -478,6 +478,25 @@ int hv_get_hypervisor_version(union hv_hypervisor_version_info *info)
>  }
>  EXPORT_SYMBOL_GPL(hv_get_hypervisor_version);
>  
> +/*
> + * Reserve vectors hard coded in the hypervisor. If used outside, the hypervisor
> + * will crash or hang or break into debugger.
> + */
> +static void hv_reserve_irq_vectors(void)
> +{
> +	#define HYPERV_DBG_FASTFAIL_VECTOR	0x29
> +	#define HYPERV_DBG_ASSERT_VECTOR	0x2C
> +	#define HYPERV_DBG_SERVICE_VECTOR	0x2D
> +
> +	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))
> +		BUG();

Would it be less hackish to use sysvec_install() with a dummy handler
for all three vectors instead? 

> +
> +	pr_info("Hyper-V:reserve vectors: %d %d %d\n", HYPERV_DBG_ASSERT_VECTOR,
> +		HYPERV_DBG_SERVICE_VECTOR, HYPERV_DBG_FASTFAIL_VECTOR);
> +}
> +
>  static void __init ms_hyperv_init_platform(void)
>  {
>  	int hv_max_functions_eax, eax;
> @@ -510,6 +529,9 @@ static void __init ms_hyperv_init_platform(void)
>  
>  	hv_identify_partition_type();
>  
> +	if (hv_root_partition())
> +		hv_reserve_irq_vectors();
> +
>  	if (cc_platform_has(CC_ATTR_SNP_SECURE_AVIC))
>  		ms_hyperv.hints |= HV_DEPRECATING_AEOI_RECOMMENDED;

-- 
Vitaly

RE: [RFC][PATCH v0] x86/hyperv: Reserve 3 interrupt vectors used exclusively by mshv

[Michael Kelley]

From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Friday, January 2, 2026 7:55 AM
> 
> Mukesh Rathor <mrathor@linux.microsoft.com> writes:
> 
> > MSVC compiler used to compile the Microsoft Hyper-V hypervisor currently,
> > has an assert intrinsic that uses interrupt vector 0x29 to create an
> > exception. This will cause hypervisor to then crash and collect core. As
> > such, if this interrupt number is assigned to a device by linux and the
> > device generates it, hypervisor will crash. There are two other such
> > vectors hard coded in the hypervisor, 0x2C and 0x2D.
> >
> > Fortunately, the three vectors are part of the kernel driver space, and
> > that makes it feasible to reserve them early so they are not assigned
> > later.
> >
> > Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
> > ---
> >  arch/x86/kernel/cpu/mshyperv.c | 22 ++++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> >
> > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> > index 579fb2c64cfd..19d41f7434df 100644
> > --- a/arch/x86/kernel/cpu/mshyperv.c
> > +++ b/arch/x86/kernel/cpu/mshyperv.c
> > @@ -478,6 +478,25 @@ int hv_get_hypervisor_version(union hv_hypervisor_version_info *info)
> >  }
> >  EXPORT_SYMBOL_GPL(hv_get_hypervisor_version);
> >
> > +/*
> > + * Reserve vectors hard coded in the hypervisor. If used outside, the hypervisor
> > + * will crash or hang or break into debugger.
> > + */
> > +static void hv_reserve_irq_vectors(void)
> > +{
> > +	#define HYPERV_DBG_FASTFAIL_VECTOR	0x29
> > +	#define HYPERV_DBG_ASSERT_VECTOR	0x2C
> > +	#define HYPERV_DBG_SERVICE_VECTOR	0x2D
> > +
> > +	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))
> > +		BUG();
> 
> Would it be less hackish to use sysvec_install() with a dummy handler
> for all three vectors instead?

It would be, but unfortunately, it doesn't work. sysvec_install() requires
that the vector be >= FIRST_SYSTEM_VECTOR, and these vectors are not.

Michael

> 
> > +
> > +	pr_info("Hyper-V:reserve vectors: %d %d %d\n", HYPERV_DBG_ASSERT_VECTOR,
> > +		HYPERV_DBG_SERVICE_VECTOR, HYPERV_DBG_FASTFAIL_VECTOR);
> > +}
> > +
> >  static void __init ms_hyperv_init_platform(void)
> >  {
> >  	int hv_max_functions_eax, eax;
> > @@ -510,6 +529,9 @@ static void __init ms_hyperv_init_platform(void)
> >
> >  	hv_identify_partition_type();
> >
> > +	if (hv_root_partition())
> > +		hv_reserve_irq_vectors();
> > +
> >  	if (cc_platform_has(CC_ATTR_SNP_SECURE_AVIC))
> >  		ms_hyperv.hints |= HV_DEPRECATING_AEOI_RECOMMENDED;
> 
> --
> Vitaly
> 

RE: [RFC][PATCH v0] x86/hyperv: Reserve 3 interrupt vectors used exclusively by mshv

[Vitaly Kuznetsov]

Michael Kelley <mhklinux@outlook.com> writes:

> From: Vitaly Kuznetsov <vkuznets@redhat.com> Sent: Friday, January 2, 2026 7:55 AM
>> 
>> Mukesh Rathor <mrathor@linux.microsoft.com> writes:
>> 
>> > MSVC compiler used to compile the Microsoft Hyper-V hypervisor currently,
>> > has an assert intrinsic that uses interrupt vector 0x29 to create an
>> > exception. This will cause hypervisor to then crash and collect core. As
>> > such, if this interrupt number is assigned to a device by linux and the
>> > device generates it, hypervisor will crash. There are two other such
>> > vectors hard coded in the hypervisor, 0x2C and 0x2D.
>> >
>> > Fortunately, the three vectors are part of the kernel driver space, and
>> > that makes it feasible to reserve them early so they are not assigned
>> > later.
>> >
>> > Signed-off-by: Mukesh Rathor <mrathor@linux.microsoft.com>
>> > ---
>> >  arch/x86/kernel/cpu/mshyperv.c | 22 ++++++++++++++++++++++
>> >  1 file changed, 22 insertions(+)
>> >
>> > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
>> > index 579fb2c64cfd..19d41f7434df 100644
>> > --- a/arch/x86/kernel/cpu/mshyperv.c
>> > +++ b/arch/x86/kernel/cpu/mshyperv.c
>> > @@ -478,6 +478,25 @@ int hv_get_hypervisor_version(union hv_hypervisor_version_info *info)
>> >  }
>> >  EXPORT_SYMBOL_GPL(hv_get_hypervisor_version);
>> >
>> > +/*
>> > + * Reserve vectors hard coded in the hypervisor. If used outside, the hypervisor
>> > + * will crash or hang or break into debugger.
>> > + */
>> > +static void hv_reserve_irq_vectors(void)
>> > +{
>> > +	#define HYPERV_DBG_FASTFAIL_VECTOR	0x29
>> > +	#define HYPERV_DBG_ASSERT_VECTOR	0x2C
>> > +	#define HYPERV_DBG_SERVICE_VECTOR	0x2D
>> > +
>> > +	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))
>> > +		BUG();
>> 
>> Would it be less hackish to use sysvec_install() with a dummy handler
>> for all three vectors instead?
>
> It would be, but unfortunately, it doesn't work. sysvec_install() requires
> that the vector be >= FIRST_SYSTEM_VECTOR, and these vectors are not.
>

True; then maybe introduce a new API like sysvec_reserve() without the
limitation? What I'm personally afraid of is that looking at
sysvec_install() it already has an additional fred_install_sysvec()
which operates over its own sysvec_table and only does
idt_install_sysvec() when !cpu_feature_enabled(X86_FEATURE_FRED) -- and
this patch just plays with system_vectors directly. Maybe this is even
correct for now but I believe can be fragile in the future.

Ultimately, I think it's up to x86 maintainers to say whether they think
that playing with system_vectors outside of the core is OK and expected
or if a new, explicit API is preferable.

-- 
Vitaly