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 <[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. >
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
