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 <[email protected]> > >>> > >>> 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 >
