On 18.03.26 10:08, Sebastian Andrzej Siewior wrote: > On 2026-03-17 12:55:15 [+0100], Jan Kiszka wrote: >> Point is that a task that was interrupted by a potentially threaded >> interrupt keeps this flag longer that it needs it. And that is >> apparently harmless, but fairly confusing. > > correct. My only concern would be a shared handler where the second is > not threaded.
The vmbus irqs are not shared (beyond what sysvec_hyperv_callback does). > >>>> With that in mind, the new logic here is no different from the one the >>>> kernel used before. If both are not doing what they should, we likely >>>> want to add a generic reset of hardirq_threaded to the IRQ exit path(s). >>> >>> The difference is that you expect that _everyone_ calling this driver >>> has everything else threaded. This might not be the case. That is why >>> this should be in core knowing what is called if threaded, use in driver >>> after explicit killing that flag afterwards since you don't know what >>> can follow or add a generic threaded infrastructure here. >> >> This driver is different, unfortunately. I'm not sure if we can / want >> to thread everything that the platform interrupt does on x86. So far, >> only the last part of it - vmbus handling - is threaded. On arm64, the >> irq is exclusive (see vmbus_percpu_isr), thus everything can be and is >> threaded. > > No, it is a percpu interrupt which are not forced-threaded. It is threaded now due to my patch. > >>>>> Couldn't the whole logic be integrated into the IRQ code? Then we could >>>>> have mask/ unmask if supported/ provided and threaded interrupts. Then >>>>> sysvec_hyperv_reenlightenment() could use a proper threaded interrupt >>>>> instead apic_eoi() + schedule_delayed_work(). >>>>> >>>> >>>> Again, you are thinking x86-only. We need a portable solution. >>> >>> well, ARM could use a threaded interrupt, too. >> >> For a reason we didn't explore in details, per-CPU interrupts aren't >> threaded. See older version of this patch >> (https://lore.kernel.org/lkml/[email protected]/) >> where I thought I only had to fix x86, but arm64 was needing care as well. > > Per-CPU are usually timers or other things which are not threaded and > have their own thing for the "second" port and I only remember MCE using > a workqueue for notification. And the hv vmbus now provides a case where threading could be useful, at least for arm64. For x86, we would have to check if the first half of sysvec_hyperv_callback (mshv_handler) wants threading as well / would support that. Jan -- Siemens AG, Foundational Technologies Linux Expert Center
