Michael Kelley <[email protected]> writes: > From: Vitaly Kuznetsov <[email protected]> Sent: Friday, January 2, 2026 > 7:55 AM >> >> Mukesh Rathor <[email protected]> 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 <[email protected]> >> > --- >> > 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
