From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 C66BF23505E; Thu, 19 Mar 2026 10:14:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773915261; cv=none; b=EFbnBdTTeUCxqRUML7oiuerVqZF8M44NlH258iE6RP4l9wBX2nmNFLs3xgCP7SMarV2NrLgwiru/VYh/Lj13kWxNSaoxe0gxtctkB6LlsIgvQl4U33I/XeqabRaT1eNL6i82PT2l/O/Ho0t9KWZpx0diETw3TKqZqNZ+37Pligo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773915261; c=relaxed/simple; bh=wGFiFEliROb2GTq8xhU2Xo5gA9vKJLiCTaG+74RMePA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=m5OWGYWeVEBhcAOWWvekEOoBCrPyY8q1nbH2dbrlKxSenkawrtC/pkaIElHxIu1u0LSJEmAIn1DDM5wsJWzaZEEu9i/uG98B6cOtZ7FFhmB4E3V6a0ewTijmbPc0IEAXSx4u+yEYsxnwvvXwrR2p5od+2gR+PT4AZrAij1++I7Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=a2m3ZHq9; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=zRS/Yqqb; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="a2m3ZHq9"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="zRS/Yqqb" Date: Thu, 19 Mar 2026 11:14:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1773915257; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=y8eZg5XkEC5aXjIN/7Q4MRHPUl4W6f7iZ0kloIeJcZA=; b=a2m3ZHq9gulwaXc2fBY0nR9dDqVo+kJQBfH8AEi5GkX2abCVrQD5NPHiwZPxquerpBEBEL oqMBQxaYnt3tzk0lQBLF3joTUdgtwaw8Pq3Ws6iGRO3uZKwnITiSx3wP5zJdgD7ZjyLQuT JB+nLR86d8H0LMb6G4nomhzsjup0wW+nLd4rLi1By+q/6YSYx3Mxv3um7HnmqtFGlgiYnf wr7WYfXzjUUiQup4uIDjfHeAAa5YJVlUjkSZ1Y1S9L++MQTuYdHfScABgUJEiTNwsJIF2n vcKzkaCHJWmUcrfa+brThrISzfLNxAK5/aI4Mg5Iw75NiDuLdb81sRqSaIWQiQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1773915257; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=y8eZg5XkEC5aXjIN/7Q4MRHPUl4W6f7iZ0kloIeJcZA=; b=zRS/Yqqb1dQTivYG8cE6NdhI+zA7Kg/TikjkGIS/oL0K/8rGxduuyr7pacgMJTQPpwDDvC KVTmDEL3MpWfKBCg== From: Sebastian Andrzej Siewior To: Michael Kelley Cc: Jan Kiszka , "K. Y. Srinivasan" , Haiyang Zhang , Wei Liu , 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 , Saurabh Singh Sengar , Naman Jain Subject: Re: RE: RE: [PATCH v3] drivers: hv: vmbus: Use kthread for vmbus interrupts on PREEMPT_RT Message-ID: <20260319101416.d60J0GjO@linutronix.de> References: <289d8e52-40f8-4b22-8aa9-d0bd3bd15aae@siemens.com> <20260312170715.HA08BHiO@linutronix.de> <20260318100138.GimjldpV@linutronix.de> Precedence: bulk X-Mailing-List: linux-hyperv@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On 2026-03-19 03:43:12 [+0000], Michael Kelley wrote: > Indeed, yes, that would remove the need for all the per-CPU interrupt hackery > on x86/x64. I don't have any objection to someone pursuing that path, but it's > not something I can do. Full disclosure: You'll see my name on Hyper-V and > VMBus stuff in the Linux kernel, with Microsoft as my employer. But I retired > from Microsoft 2.5 years ago, and my current involvement in Linux kernel work > is purely as a very part-time volunteer. I also lack access to hardware and the > test machinery needed to make more significant changes, particularly if multiple > versions of Hyper-V must be tested. right. Then I would only ask for better annotation instead this current thingy. > > I would be worried if the host would storming interrupts to the guest > > because it makes no progress. > > No, that kind of storming won't happen. The Hyper-V host<->guest > interface is based on message queues. The host interrupts the guest > if it puts a message in the queue that transitions the queue from > "empty" to "not empty". Eventually the tasklet enabled in vmbus_isr() > and its subsidiaries gets around to emptying the queue, which effectively > re-arms the interrupt. The host may add more messages to the queue, > but it doesn't interrupt again for that queue until the queue is empty. > If the guest is delayed in doing that emptying, nothing bad happens. Okay. > > > > Moving on. This (trying very hard here) even schedules tasklets. Why? > > > > You need to disable BH before doing so. Otherwise it ends in ksoftirqd. > > > > You don't want that. > > > > > > Again, Jan can comment on the impact of delays due to ending up > > > in ksoftirqd. > > > > My point is that having this with threaded interrupt support would > > eliminate the usage of tasklets. > > Agreed, probably. For the non-RT case, the latency in getting to the > tasklet code *does* matter. I'm not familiar with how tasklets compare > to threaded interrupts on latency. There shouldn't be much difference on level where it actually matters. Sebastian