From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH 6/6] kvm: x86: do not use KVM_REQ_EVENT for APICv interrupt injection Date: Thu, 9 Feb 2017 16:11:46 +0100 Message-ID: <20170209151145.GK31091@potion> References: <1482164232-130035-1-git-send-email-pbonzini@redhat.com> <1482164232-130035-7-git-send-email-pbonzini@redhat.com> <20170207195804.GA1473@potion> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, "Wu, Feng" To: Paolo Bonzini Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 2017-02-08 17:23+0100, Paolo Bonzini: > On 07/02/2017 20:58, Radim Krčmář wrote: >>> - local_irq_disable(); >>> + if (kvm_lapic_enabled(vcpu)) { >>> + /* >>> + * This handles the case where a posted interrupt was >>> + * notified with kvm_vcpu_kick. >>> + */ >>> + if (kvm_x86_ops->sync_pir_to_irr) >>> + kvm_x86_ops->sync_pir_to_irr(vcpu); >> Hm, this is not working well when nesting while L1 has assigned devices: >> if the posted interrupt arrives just before local_irq_disable(), then >> we'll just enter L2 instead of doing a nested VM exit (in case we have >> interrupt exiting). >> >> And after reading the code a bit, I think we allow posted interrupts in >> L2 while L1 has assigned devices that use posted interrupts, and that it >> doesn't work. > > So you mean the interrupt is delivered to L2? The fix would be to wrap > L2 entry and exit with some subset of pi_pre_block/pi_post_block. I hope not, as their PI strucutres are separate, so we'd be just delaying the interrupt injection to L1. The CPU running L2 guest will notice a posted notification, but its PIR.ON will/might not be set. L1's PIR.ON will be set, but no-one is going to care until the next VM exit. I'll add some unit tests to check that I understood the bug correctly. Changing the notification vector for L2 would be an ok solution. We'd reserve a new vector in L0 and check L1's interrupts. If it were targetting a VCPU that is currently in L2 with a notification vector configured for L2, we'd translate that vector into the notification vector we set for L2 -- L1 could then post interrupts to L2 without a VM exit. And "posted" interrupts for L1 while in L2 would trigger a VM exit, because the notification vector would be different.