arch/x86/kernel/cpu/mshyperv.c | 52 ++++++++++++++++++++++++++++++++-- 1 file changed, 50 insertions(+), 2 deletions(-)
From: Jan Kiszka <jan.kiszka@siemens.com>
Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V
with related guest support enabled:
[ 1.127941] hv_vmbus: registering driver hyperv_drm
[ 1.132518] =============================
[ 1.132519] [ BUG: Invalid wait context ]
[ 1.132521] 6.19.0-rc8+ #9 Not tainted
[ 1.132524] -----------------------------
[ 1.132525] swapper/0/0 is trying to lock:
[ 1.132526] ffff8b9381bb3c90 (&channel->sched_lock){....}-{3:3}, at: vmbus_chan_sched+0xc4/0x2b0
[ 1.132543] other info that might help us debug this:
[ 1.132544] context-{2:2}
[ 1.132545] 1 lock held by swapper/0/0:
[ 1.132547] #0: ffffffffa010c4c0 (rcu_read_lock){....}-{1:3}, at: vmbus_chan_sched+0x31/0x2b0
[ 1.132557] stack backtrace:
[ 1.132560] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-rc8+ #9 PREEMPT_{RT,(lazy)}
[ 1.132565] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/25/2025
[ 1.132567] Call Trace:
[ 1.132570] <IRQ>
[ 1.132573] dump_stack_lvl+0x6e/0xa0
[ 1.132581] __lock_acquire+0xee0/0x21b0
[ 1.132592] lock_acquire+0xd5/0x2d0
[ 1.132598] ? vmbus_chan_sched+0xc4/0x2b0
[ 1.132606] ? lock_acquire+0xd5/0x2d0
[ 1.132613] ? vmbus_chan_sched+0x31/0x2b0
[ 1.132619] rt_spin_lock+0x3f/0x1f0
[ 1.132623] ? vmbus_chan_sched+0xc4/0x2b0
[ 1.132629] ? vmbus_chan_sched+0x31/0x2b0
[ 1.132634] vmbus_chan_sched+0xc4/0x2b0
[ 1.132641] vmbus_isr+0x2c/0x150
[ 1.132648] __sysvec_hyperv_callback+0x5f/0xa0
[ 1.132654] sysvec_hyperv_callback+0x88/0xb0
[ 1.132658] </IRQ>
[ 1.132659] <TASK>
[ 1.132660] asm_sysvec_hyperv_callback+0x1a/0x20
As code paths that handle vmbus IRQs use sleepy locks under PREEMPT_RT,
the complete vmbus_handler execution needs to be moved into thread
context. Open-coding this allows to skip the IPI that irq_work would
additionally bring and which we do not need, being an IRQ, never an NMI.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
This should resolve what was once brought forward via [1]. If it
actually resolves all remaining compatibility issues of the hyperv
support with RT is not yet clear, though. So far, lockdep is happy when
using this plus [2].
[1] https://lore.kernel.org/all/20230809-b4-rt_preempt-fix-v1-0-7283bbdc8b14@gmail.com/
[2] https://lore.kernel.org/lkml/0c7fb5cd-fb21-4760-8593-e04bade84744@siemens.com/
arch/x86/kernel/cpu/mshyperv.c | 52 ++++++++++++++++++++++++++++++++--
1 file changed, 50 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 579fb2c64cfd..1194ca452c52 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -17,6 +17,7 @@
#include <linux/irq.h>
#include <linux/kexec.h>
#include <linux/random.h>
+#include <linux/smpboot.h>
#include <asm/processor.h>
#include <asm/hypervisor.h>
#include <hyperv/hvhdk.h>
@@ -150,6 +151,43 @@ static void (*hv_stimer0_handler)(void);
static void (*hv_kexec_handler)(void);
static void (*hv_crash_handler)(struct pt_regs *regs);
+static DEFINE_PER_CPU(bool, vmbus_irq_pending);
+static DEFINE_PER_CPU(struct task_struct *, vmbus_irqd);
+
+static void vmbus_irqd_wake(void)
+{
+ struct task_struct *tsk = __this_cpu_read(vmbus_irqd);
+
+ __this_cpu_write(vmbus_irq_pending, true);
+ wake_up_process(tsk);
+}
+
+static void vmbus_irqd_setup(unsigned int cpu)
+{
+ sched_set_fifo(current);
+}
+
+static int vmbus_irqd_should_run(unsigned int cpu)
+{
+ return __this_cpu_read(vmbus_irq_pending);
+}
+
+static void run_vmbus_irqd(unsigned int cpu)
+{
+ vmbus_handler();
+ __this_cpu_write(vmbus_irq_pending, false);
+}
+
+static bool vmbus_irq_initialized;
+
+static struct smp_hotplug_thread vmbus_irq_threads = {
+ .store = &vmbus_irqd,
+ .setup = vmbus_irqd_setup,
+ .thread_should_run = vmbus_irqd_should_run,
+ .thread_fn = run_vmbus_irqd,
+ .thread_comm = "vmbus_irq/%u",
+};
+
DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback)
{
struct pt_regs *old_regs = set_irq_regs(regs);
@@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback)
if (mshv_handler)
mshv_handler();
- if (vmbus_handler)
- vmbus_handler();
+ if (vmbus_handler) {
+ if (IS_ENABLED(CONFIG_PREEMPT_RT))
+ vmbus_irqd_wake();
+ else
+ vmbus_handler();
+ }
if (ms_hyperv.hints & HV_DEPRECATING_AEOI_RECOMMENDED)
apic_eoi();
@@ -174,6 +216,10 @@ void hv_setup_mshv_handler(void (*handler)(void))
void hv_setup_vmbus_handler(void (*handler)(void))
{
+ if (IS_ENABLED(CONFIG_PREEMPT_RT) && !vmbus_irq_initialized) {
+ BUG_ON(smpboot_register_percpu_thread(&vmbus_irq_threads));
+ vmbus_irq_initialized = true;
+ }
vmbus_handler = handler;
}
@@ -181,6 +227,8 @@ void hv_remove_vmbus_handler(void)
{
/* We have no way to deallocate the interrupt gate */
vmbus_handler = NULL;
+ smpboot_unregister_percpu_thread(&vmbus_irq_threads);
+ vmbus_irq_initialized = false;
}
/*
--
2.51.0On Tue, 2026-02-03 at 17:01 +0100, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V
> with related guest support enabled:
>
> [ 1.127941] hv_vmbus: registering driver hyperv_drm
>
> [ 1.132518] =============================
> [ 1.132519] [ BUG: Invalid wait context ]
> [ 1.132521] 6.19.0-rc8+ #9 Not tainted
> [ 1.132524] -----------------------------
> [ 1.132525] swapper/0/0 is trying to lock:
> [ 1.132526] ffff8b9381bb3c90 (&channel->sched_lock){....}-{3:3}, at: vmbus_chan_sched+0xc4/0x2b0
> [ 1.132543] other info that might help us debug this:
> [ 1.132544] context-{2:2}
> [ 1.132545] 1 lock held by swapper/0/0:
> [ 1.132547] #0: ffffffffa010c4c0 (rcu_read_lock){....}-{1:3}, at: vmbus_chan_sched+0x31/0x2b0
> [ 1.132557] stack backtrace:
> [ 1.132560] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-rc8+ #9 PREEMPT_{RT,(lazy)}
> [ 1.132565] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/25/2025
> [ 1.132567] Call Trace:
> [ 1.132570] <IRQ>
> [ 1.132573] dump_stack_lvl+0x6e/0xa0
> [ 1.132581] __lock_acquire+0xee0/0x21b0
> [ 1.132592] lock_acquire+0xd5/0x2d0
> [ 1.132598] ? vmbus_chan_sched+0xc4/0x2b0
> [ 1.132606] ? lock_acquire+0xd5/0x2d0
> [ 1.132613] ? vmbus_chan_sched+0x31/0x2b0
> [ 1.132619] rt_spin_lock+0x3f/0x1f0
> [ 1.132623] ? vmbus_chan_sched+0xc4/0x2b0
> [ 1.132629] ? vmbus_chan_sched+0x31/0x2b0
> [ 1.132634] vmbus_chan_sched+0xc4/0x2b0
> [ 1.132641] vmbus_isr+0x2c/0x150
> [ 1.132648] __sysvec_hyperv_callback+0x5f/0xa0
> [ 1.132654] sysvec_hyperv_callback+0x88/0xb0
> [ 1.132658] </IRQ>
> [ 1.132659] <TASK>
> [ 1.132660] asm_sysvec_hyperv_callback+0x1a/0x20
>
> As code paths that handle vmbus IRQs use sleepy locks under PREEMPT_RT,
> the complete vmbus_handler execution needs to be moved into thread
> context. Open-coding this allows to skip the IPI that irq_work would
> additionally bring and which we do not need, being an IRQ, never an NMI.
>
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Tested-by: Florian Bezdeka <florian.bezdeka@siemens.com>
This patch survived a 24h stress test with CONFIG_PREEMPT_RT enabled and
heavy load applied to the system.
There was no lockup happening without this patch. The lockdep warning is
gone now.
Best regards,
Florian
--
Siemens AG, Foundational Technologies
Linux Expert Center
On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V
> with related guest support enabled:
So all it takes to reproduce this is to enabled PREEMPT_RT?
Asking because ...
> struct pt_regs *old_regs = set_irq_regs(regs);
> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback)
> if (mshv_handler)
> mshv_handler();
... to err on the safe side we should probably do the same for
mshv_handler as well.
Note we don't support RT yet, but if issues are found we might as well
just fix them up.
How urgent do you want this patch to get applied?
Thanks,
Wei
>
> - if (vmbus_handler)
> - vmbus_handler();
> + if (vmbus_handler) {
> + if (IS_ENABLED(CONFIG_PREEMPT_RT))
> + vmbus_irqd_wake();
> + else
> + vmbus_handler();
> + }
>
> if (ms_hyperv.hints & HV_DEPRECATING_AEOI_RECOMMENDED)
> apic_eoi();
> @@ -174,6 +216,10 @@ void hv_setup_mshv_handler(void (*handler)(void))
>
> void hv_setup_vmbus_handler(void (*handler)(void))
> {
> + if (IS_ENABLED(CONFIG_PREEMPT_RT) && !vmbus_irq_initialized) {
> + BUG_ON(smpboot_register_percpu_thread(&vmbus_irq_threads));
> + vmbus_irq_initialized = true;
> + }
> vmbus_handler = handler;
> }
>
> @@ -181,6 +227,8 @@ void hv_remove_vmbus_handler(void)
> {
> /* We have no way to deallocate the interrupt gate */
> vmbus_handler = NULL;
> + smpboot_unregister_percpu_thread(&vmbus_irq_threads);
> + vmbus_irq_initialized = false;
> }
>
> /*
> --
> 2.51.0
On 04.02.26 08:00, Wei Liu wrote: > On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote: >> From: Jan Kiszka <jan.kiszka@siemens.com> >> >> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V >> with related guest support enabled: > > So all it takes to reproduce this is to enabled PREEMPT_RT? > ...and enable CONFIG_PROVE_LOCKING so that you do not have to wait for your system to actually run into the bug. Lockdep already triggers during bootup. > Asking because ... > >> struct pt_regs *old_regs = set_irq_regs(regs); >> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback) >> if (mshv_handler) >> mshv_handler(); > > ... to err on the safe side we should probably do the same for > mshv_handler as well. > Valid question. We so far worked based on lockdep reports, and the mshv_handler didn't trigger yet. Either it is not run in our setup, or it is actually already fine. But I have a code review on my agenda regarding potential remaining issues in mshv. Is there something needed to trigger the mshv_handler so that we can test it? > Note we don't support RT yet, but if issues are found we might as well > just fix them up. This is actually not about RT itself but about supporting all configurable locking semantics of the. And the mshv drivers fail here. > > How urgent do you want this patch to get applied? If I asked my folks: yesterday (we shipped it...). We would also need in upstream stable and stable-rt, though it may not reach the current production kernel anymore (6.1-rt from bookworm) because it reaching EOL in a few months. Jan -- Siemens AG, Foundational Technologies Linux Expert Center
On 04.02.26 08:19, Jan Kiszka wrote: > On 04.02.26 08:00, Wei Liu wrote: >> On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote: >>> From: Jan Kiszka <jan.kiszka@siemens.com> >>> >>> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V >>> with related guest support enabled: >> >> So all it takes to reproduce this is to enabled PREEMPT_RT? >> > > ...and enable CONFIG_PROVE_LOCKING so that you do not have to wait for > your system to actually run into the bug. Lockdep already triggers > during bootup. > >> Asking because ... >> >>> struct pt_regs *old_regs = set_irq_regs(regs); >>> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback) >>> if (mshv_handler) >>> mshv_handler(); >> >> ... to err on the safe side we should probably do the same for >> mshv_handler as well. >> > > Valid question. We so far worked based on lockdep reports, and the > mshv_handler didn't trigger yet. Either it is not run in our setup, or > it is actually already fine. But I have a code review on my agenda > regarding potential remaining issues in mshv. > > Is there something needed to trigger the mshv_handler so that we can > test it? > Ah, that depends on CONFIG_MSHV_ROOT. Is that related to the accelerator mode that Magnus presented in [1]? We briefly chatted about it and also my problems with the drivers after his talk on Saturday. Jan [1] https://fosdem.org/2026/schedule/event/BFQ8XA-introducing-mshv-accelerator-in-qemu/ -- Siemens AG, Foundational Technologies Linux Expert Center
On Wed, Feb 04, 2026 at 08:26:48AM +0100, Jan Kiszka wrote: > On 04.02.26 08:19, Jan Kiszka wrote: > > On 04.02.26 08:00, Wei Liu wrote: > >> On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote: > >>> From: Jan Kiszka <jan.kiszka@siemens.com> > >>> > >>> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V > >>> with related guest support enabled: > >> > >> So all it takes to reproduce this is to enabled PREEMPT_RT? > >> > > > > ...and enable CONFIG_PROVE_LOCKING so that you do not have to wait for > > your system to actually run into the bug. Lockdep already triggers > > during bootup. > > > >> Asking because ... > >> > >>> struct pt_regs *old_regs = set_irq_regs(regs); > >>> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback) > >>> if (mshv_handler) > >>> mshv_handler(); > >> > >> ... to err on the safe side we should probably do the same for > >> mshv_handler as well. > >> > > > > Valid question. We so far worked based on lockdep reports, and the > > mshv_handler didn't trigger yet. Either it is not run in our setup, or > > it is actually already fine. But I have a code review on my agenda > > regarding potential remaining issues in mshv. > > > > Is there something needed to trigger the mshv_handler so that we can > > test it? > > > > Ah, that depends on CONFIG_MSHV_ROOT. Is that related to the accelerator > mode that Magnus presented in [1]? We briefly chatted about it and also > my problems with the drivers after his talk on Saturday. Yes. That is the driver. If PROVE_LOCKING triggers the warning without running the code, perhaps turning on MSHV_ROOT is enough. Wei > > Jan > > [1] > https://fosdem.org/2026/schedule/event/BFQ8XA-introducing-mshv-accelerator-in-qemu/ > > -- > Siemens AG, Foundational Technologies > Linux Expert Center >
On 04.02.26 08:29, Wei Liu wrote: > On Wed, Feb 04, 2026 at 08:26:48AM +0100, Jan Kiszka wrote: >> On 04.02.26 08:19, Jan Kiszka wrote: >>> On 04.02.26 08:00, Wei Liu wrote: >>>> On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote: >>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>> >>>>> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V >>>>> with related guest support enabled: >>>> >>>> So all it takes to reproduce this is to enabled PREEMPT_RT? >>>> >>> >>> ...and enable CONFIG_PROVE_LOCKING so that you do not have to wait for >>> your system to actually run into the bug. Lockdep already triggers >>> during bootup. >>> >>>> Asking because ... >>>> >>>>> struct pt_regs *old_regs = set_irq_regs(regs); >>>>> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback) >>>>> if (mshv_handler) >>>>> mshv_handler(); >>>> >>>> ... to err on the safe side we should probably do the same for >>>> mshv_handler as well. >>>> >>> >>> Valid question. We so far worked based on lockdep reports, and the >>> mshv_handler didn't trigger yet. Either it is not run in our setup, or >>> it is actually already fine. But I have a code review on my agenda >>> regarding potential remaining issues in mshv. >>> >>> Is there something needed to trigger the mshv_handler so that we can >>> test it? >>> >> >> Ah, that depends on CONFIG_MSHV_ROOT. Is that related to the accelerator >> mode that Magnus presented in [1]? We briefly chatted about it and also >> my problems with the drivers after his talk on Saturday. > > Yes. That is the driver. If PROVE_LOCKING triggers the warning without > running the code, perhaps turning on MSHV_ROOT is enough. > But if my VM is not a root partition, I wouldn't use that driver, would I? Jan -- Siemens AG, Foundational Technologies Linux Expert Center
On Wed, Feb 04, 2026 at 08:32:04AM +0100, Jan Kiszka wrote: > On 04.02.26 08:29, Wei Liu wrote: > > On Wed, Feb 04, 2026 at 08:26:48AM +0100, Jan Kiszka wrote: > >> On 04.02.26 08:19, Jan Kiszka wrote: > >>> On 04.02.26 08:00, Wei Liu wrote: > >>>> On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote: > >>>>> From: Jan Kiszka <jan.kiszka@siemens.com> > >>>>> > >>>>> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V > >>>>> with related guest support enabled: > >>>> > >>>> So all it takes to reproduce this is to enabled PREEMPT_RT? > >>>> > >>> > >>> ...and enable CONFIG_PROVE_LOCKING so that you do not have to wait for > >>> your system to actually run into the bug. Lockdep already triggers > >>> during bootup. > >>> > >>>> Asking because ... > >>>> > >>>>> struct pt_regs *old_regs = set_irq_regs(regs); > >>>>> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback) > >>>>> if (mshv_handler) > >>>>> mshv_handler(); > >>>> > >>>> ... to err on the safe side we should probably do the same for > >>>> mshv_handler as well. > >>>> > >>> > >>> Valid question. We so far worked based on lockdep reports, and the > >>> mshv_handler didn't trigger yet. Either it is not run in our setup, or > >>> it is actually already fine. But I have a code review on my agenda > >>> regarding potential remaining issues in mshv. > >>> > >>> Is there something needed to trigger the mshv_handler so that we can > >>> test it? > >>> > >> > >> Ah, that depends on CONFIG_MSHV_ROOT. Is that related to the accelerator > >> mode that Magnus presented in [1]? We briefly chatted about it and also > >> my problems with the drivers after his talk on Saturday. > > > > Yes. That is the driver. If PROVE_LOCKING triggers the warning without > > running the code, perhaps turning on MSHV_ROOT is enough. > > > > But if my VM is not a root partition, I wouldn't use that driver, would I? No, you wouldn't. You cannot do that until later this year. If you cannot test that, so be it. I'm fine with applying your patch and then move the mshv_handler logic later ourselves. I've CC'ed a few folks from Microsoft. Saurabh, Long, and Dexuan, can you review and test this patch for VMBus? Thanks, Wei > > Jan > > -- > Siemens AG, Foundational Technologies > Linux Expert Center >
On 2/4/2026 1:06 PM, Wei Liu wrote: > On Wed, Feb 04, 2026 at 08:32:04AM +0100, Jan Kiszka wrote: >> On 04.02.26 08:29, Wei Liu wrote: >>> On Wed, Feb 04, 2026 at 08:26:48AM +0100, Jan Kiszka wrote: >>>> On 04.02.26 08:19, Jan Kiszka wrote: >>>>> On 04.02.26 08:00, Wei Liu wrote: >>>>>> On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote: >>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>> >>>>>>> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V >>>>>>> with related guest support enabled: >>>>>> >>>>>> So all it takes to reproduce this is to enabled PREEMPT_RT? >>>>>> >>>>> >>>>> ...and enable CONFIG_PROVE_LOCKING so that you do not have to wait for >>>>> your system to actually run into the bug. Lockdep already triggers >>>>> during bootup. >>>>> >>>>>> Asking because ... >>>>>> >>>>>>> struct pt_regs *old_regs = set_irq_regs(regs); >>>>>>> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback) >>>>>>> if (mshv_handler) >>>>>>> mshv_handler(); >>>>>> >>>>>> ... to err on the safe side we should probably do the same for >>>>>> mshv_handler as well. >>>>>> >>>>> >>>>> Valid question. We so far worked based on lockdep reports, and the >>>>> mshv_handler didn't trigger yet. Either it is not run in our setup, or >>>>> it is actually already fine. But I have a code review on my agenda >>>>> regarding potential remaining issues in mshv. >>>>> >>>>> Is there something needed to trigger the mshv_handler so that we can >>>>> test it? >>>>> >>>> >>>> Ah, that depends on CONFIG_MSHV_ROOT. Is that related to the accelerator >>>> mode that Magnus presented in [1]? We briefly chatted about it and also >>>> my problems with the drivers after his talk on Saturday. >>> >>> Yes. That is the driver. If PROVE_LOCKING triggers the warning without >>> running the code, perhaps turning on MSHV_ROOT is enough. >>> >> >> But if my VM is not a root partition, I wouldn't use that driver, would I? > > No, you wouldn't. You cannot do that until later this year. If you > cannot test that, so be it. I'm fine with applying your patch and then > move the mshv_handler logic later ourselves. > > I've CC'ed a few folks from Microsoft. > > Saurabh, Long, and Dexuan, can you review and test this patch for VMBus? I tested this and didn't see any issues with OpenHCL/mshv_vtl. Regards, Naman
On 04.02.26 08:36, Wei Liu wrote: > On Wed, Feb 04, 2026 at 08:32:04AM +0100, Jan Kiszka wrote: >> On 04.02.26 08:29, Wei Liu wrote: >>> On Wed, Feb 04, 2026 at 08:26:48AM +0100, Jan Kiszka wrote: >>>> On 04.02.26 08:19, Jan Kiszka wrote: >>>>> On 04.02.26 08:00, Wei Liu wrote: >>>>>> On Tue, Feb 03, 2026 at 05:01:30PM +0100, Jan Kiszka wrote: >>>>>>> From: Jan Kiszka <jan.kiszka@siemens.com> >>>>>>> >>>>>>> Resolves the following lockdep report when booting PREEMPT_RT on Hyper-V >>>>>>> with related guest support enabled: >>>>>> >>>>>> So all it takes to reproduce this is to enabled PREEMPT_RT? >>>>>> >>>>> >>>>> ...and enable CONFIG_PROVE_LOCKING so that you do not have to wait for >>>>> your system to actually run into the bug. Lockdep already triggers >>>>> during bootup. >>>>> >>>>>> Asking because ... >>>>>> >>>>>>> struct pt_regs *old_regs = set_irq_regs(regs); >>>>>>> @@ -158,8 +196,12 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_hyperv_callback) >>>>>>> if (mshv_handler) >>>>>>> mshv_handler(); >>>>>> >>>>>> ... to err on the safe side we should probably do the same for >>>>>> mshv_handler as well. >>>>>> >>>>> >>>>> Valid question. We so far worked based on lockdep reports, and the >>>>> mshv_handler didn't trigger yet. Either it is not run in our setup, or >>>>> it is actually already fine. But I have a code review on my agenda >>>>> regarding potential remaining issues in mshv. >>>>> >>>>> Is there something needed to trigger the mshv_handler so that we can >>>>> test it? >>>>> >>>> >>>> Ah, that depends on CONFIG_MSHV_ROOT. Is that related to the accelerator >>>> mode that Magnus presented in [1]? We briefly chatted about it and also >>>> my problems with the drivers after his talk on Saturday. >>> >>> Yes. That is the driver. If PROVE_LOCKING triggers the warning without >>> running the code, perhaps turning on MSHV_ROOT is enough. >>> >> >> But if my VM is not a root partition, I wouldn't use that driver, would I? > > No, you wouldn't. You cannot do that until later this year. If you > cannot test that, so be it. I'm fine with applying your patch and then > move the mshv_handler logic later ourselves. Based on my review, I bet you have to lift the mshv_handler to a thread as well, e.g. sysvec_hyperv_callback ... -> kick_vp -> wake_up. OTOH, the probability that someone tries to use PREEMPT_RT as root Linux is likely even lower than someone trying it as a normal guest. IMHO, you could also consider to rule out that combination at Kconfig level. Jan -- Siemens AG, Foundational Technologies Linux Expert Center
© 2016 - 2026 Red Hat, Inc.