From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD7932BE630; Wed, 4 Feb 2026 07:29:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770190172; cv=none; b=h+vPU37uWUTTp2WDAhUMXj2pK6N1uq7njGuq535xiGN6lptNcSh4Q3Pws/Xrk1O6btED6f67323lP0OX1b/r9FhyQ7dpPHIH4PvbQrduMrYrE4cZSSD/+ILnT7V6YF3GcnOJWJ6sqpnIyELasZAjqy7Yh0X2L6SQR5YhUONWF2E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770190172; c=relaxed/simple; bh=xxWg4NATlQnnRZAA+H5DGTM81NA/jsuCbJ86jsJjATg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SppXaoixEID/zSTJF1ub5KtJXqIvcZTTdL/Gc4WGGNzSD3UTed05gfr9BAOjFYYHe8dcidqCcutT73HIYyRdlwCJW4iI71w7ymB3WM2l3ypSH1SMmBAvL7thLsc8q5uUIxqTOPHZaOtV/Ts6weRwY/6y9BZiI5tTRHE92M7jNKU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=De7bxztN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="De7bxztN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31133C4CEF7; Wed, 4 Feb 2026 07:29:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770190172; bh=xxWg4NATlQnnRZAA+H5DGTM81NA/jsuCbJ86jsJjATg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=De7bxztNz1Fbm5dYJ3hK2UXPimHWoB6gko1bYrjdJiRsU/OlNqEXzpKIHB1GVxqqf LoeCXd4Fmbr963NxB9UUBX1xvDuq56l043/y2ubbyzGBc8rsNRBbUHIfBn4ihbQUj7 k0TZpv9uNVHxrQCVGfX5pDG5DVi1kggLnIIklCaof1VJplsH12UmEPlDe41nqYdskC vmxS6BbwnTtweWlE/6nMtOmJmBMbHhKFpY/JhCEcpPeHublGS1WUm92RnP6s1X9bdG IC7zUweon+kRzfmLOwNB07HNCEc4MEG4igH5jhdC6/rn8K8T4cfjvZaTjC2bCwU0WU byFpTjOKbXONw== Date: Wed, 4 Feb 2026 07:29:30 +0000 From: Wei Liu To: Jan Kiszka Cc: Wei Liu , Magnus Kulke , "K. Y. Srinivasan" , Haiyang Zhang , Dexuan Cui , Long Li , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, Florian Bezdeka , RT , Mitchell Levy Subject: Re: [PATCH] x86: mshyperv: Use kthread for vmbus interrupts on PREEMPT_RT Message-ID: <20260204072930.GO79272@liuwe-devbox-debian-v2.local> References: <133a95d9-8148-40ea-9acc-edfd8e3ceef4@siemens.com> <20260204070004.GM79272@liuwe-devbox-debian-v2.local> <10ec70f2-27a5-477f-b6e9-164f7b7545d9@siemens.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10ec70f2-27a5-477f-b6e9-164f7b7545d9@siemens.com> 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 > >>> > >>> 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 >