On Tue, Jun 04, 2024, Manali Shukla wrote:
> On 5/28/2024 3:52 PM, Paolo Bonzini wrote:
> > Does this have an effect on the number of vmexits for KVM, unless AVIC
> > is enabled?
Ah, I suspect it will (as Manali's trace shows), because KVM will pend a V_INTR
(V_IRQ in KVM's world) in order to detect the interrupt window. And while KVM
will still exit on the V_INTR, it'll avoid an exit on HLT.
Of course, we could (should?) address that in KVM by clearing the V_INTR (and
its
intercept) when there are no pending, injectable IRQs at the end of
kvm_check_and_inject_events(). VMX would benefit from that change as well.
I think it's just this? Because enabling an IRQ window for userspace happens
after this.
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index af6c8cf6a37a..373c850cc325 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -10556,9 +10556,11 @@ static int kvm_check_and_inject_events(struct kvm_vcpu
*vcpu,
WARN_ON(kvm_x86_call(interrupt_allowed)(vcpu,
true) < 0);
}
}
- if (kvm_cpu_has_injectable_intr(vcpu))
- kvm_x86_call(enable_irq_window)(vcpu);
}
+ if (kvm_cpu_has_injectable_intr(vcpu))
+ kvm_x86_call(enable_irq_window)(vcpu);
+ else
+ kvm_x86_call(disable_irq_window)(vcpu);
if (is_guest_mode(vcpu) &&
kvm_x86_ops.nested_ops->has_events &&
> Snippet of the Test case:
> +static void idle_hlt_test(void)
> +{
> + x = 0;
> + cli();
> + apic_self_ipi(IPI_TEST_VECTOR);
> + safe_halt();
> + if (x != 1) printf("%d", x);
> +}
This isn't very representative of real world behavior. In practice, the window
for a wake event to arrive between CLI and STI;HLT is quite small, i.e. having a
V_INTR (or V_NMI) pending when HLT is executed is fairly uncommon.
A more compelling benchmark would be something like a netperf latency test.
I honestly don't know how high of a bar we should set for this feature. On one
hand, it's a tiny amount of enabling. On the other hand, it would be extremely
unfortunate if this somehow caused latency/throughput regressions, which seems
highly improbably, but never say never...
