On Tue, Jul 08, 2025 at 10:11:18AM -0700, Stefano Stabellini wrote: > On Tue, 8 Jul 2025, Jan Beulich wrote: > > On 08.07.2025 12:11, Roger Pau Monné wrote: > > > On Mon, Jul 07, 2025 at 05:06:53PM -0700, Stefano Stabellini wrote: > > > Interrupt forwarding > > > from Xen into HVM/PVH guests uses a softirq to do the injection, which > > > means there's a non-deterministic window of latency between when the > > > interrupt is received by Xen, as to when it's injected to the guest, > > > because the softirq might not get processed right after being set as > > > pending (there might be other softirqs to process, or simply Xen might > > > be busy doing some other operation). > > > > > > I think you want to look into adding a new command line option or > > > similar, that allows selecting whether guest IRQs are deferred to a > > > softirq for injection, or are injected as part of the processing done > > > in the IRQ handler itself. > > > > > > Otherwise there will always be a non-deterministic amount of latency > > > on x86 w.r.t. HVM/PVH passthrough guest interrupts. Haven't you seen > > > some weird/unexpected variance when doing this passthrough interrupt > > > latency measurements on x86? > > While this is not great and I agree with Roger that it should be > improved (I'll try to do so), in a well configured system I expect that > there should be no other softirqs on the RTOS vCPU/pCPU so it shouldn't > matter much if it is raise as a softirq or not?
Possibly - if the physical CPU where the interrupt is injected is also the one where the target vCPU is running it won't make much of a difference whether injection to the guest is deferred to a softirq, as softirqs must always be processed before returning to guest context. So I would think that when using the interrupt-follows-vCPU Xen model, where interrupts are moved around to follow the vCPUs they target, this extra latency would only be seen when the interrupt is delivered to a CPU different than the one where the target guest vCPU is running, which is never in your scenario because you pin vCPUs. Roger.
