Jan Kiszka wrote:
> Bernhard Kohl wrote:
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index 5cf28df..eca57a3 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -3357,7 +3357,8 @@ static void vmx_intr_assist(struct kvm_vcpu *vcpu)
>> enable_irq_window(vcpu);
>> }
>> if (vcpu->arch.interrupt.pending) {
>> - vmx_inject_irq(vcpu, vcpu->arch.interrupt.nr);
>> + if (vcpu->arch.interrupt_window_open)
>> + vmx_inject_irq(vcpu, vcpu->arch.interrupt.nr);
>> if (kvm_cpu_has_interrupt(vcpu))
>> enable_irq_window(vcpu);
>> }
>
> That causes concerns on my side as we had a hard time stabilizing this
> code. Need to think about it. Do you happen to have a test case for this
> (if it's not publicly shareable, contact me directly)? Did you check
> that this change causes no obvious regressions to other guests? What
> about the user-inject IRQ case, does it already work for you as-is?
Hmm, do_interrupt_requests will most likely not cause troubles as it
both pends and injects interrupts only when the window if open. I don't
get the scenario behind this here yet, but I think it would be a very
good chance to align the code layout of vmx_intr_assist to
do_interrupt_requests in this respect, either finally de-optimizing or
even breaking both :) - or bringing them in the same correct form.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
