Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934806AbcJZUGS (ORCPT ); Wed, 26 Oct 2016 16:06:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38820 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933440AbcJZUGO (ORCPT ); Wed, 26 Oct 2016 16:06:14 -0400 Date: Wed, 26 Oct 2016 22:05:35 +0200 From: Radim =?utf-8?B?S3LEjW3DocWZ?= To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, yang.zhang.wz@gmail.com, feng.wu@intel.com, mst@redhat.com Subject: Re: [PATCH 3/5] KVM: x86: do not use KVM_REQ_EVENT for APICv interrupt injection Message-ID: <20161026200534.GD4212@potion> References: <1476469291-5039-1-git-send-email-pbonzini@redhat.com> <1476469291-5039-4-git-send-email-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1476469291-5039-4-git-send-email-pbonzini@redhat.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 26 Oct 2016 20:05:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2025 Lines: 37 2016-10-14 20:21+0200, Paolo Bonzini: > Since bf9f6ac8d749 ("KVM: Update Posted-Interrupts Descriptor when vCPU > is blocked", 2015-09-18) the posted interrupt descriptor is checked > unconditionally for PIR.ON. Therefore we don't need KVM_REQ_EVENT to > trigger the scan and, if NMIs or SMIs are not involved, we can avoid > the complicated event injection path. > > Calling kvm_vcpu_kick if PIR.ON=1 is also useless, though it has been > there since APICv was introduced. > > However, without the KVM_REQ_EVENT safety net KVM needs to be much > more careful about races between vmx_deliver_posted_interrupt and > vcpu_enter_guest. First, the IPI for posted interrupts may be issued > between setting vcpu->mode = IN_GUEST_MODE and disabling interrupts. > If that happens, kvm_trigger_posted_interrupt returns true, but > smp_kvm_posted_intr_ipi doesn't do anything about it. The guest is > entered with PIR.ON, but the posted interrupt IPI has not been sent > and the interrupt is only delivered to the guest on the next vmentry > (if any). To fix this, disable interrupts before setting vcpu->mode. > This ensures that the IPI is delayed until the guest enters non-root mode; > it is then trapped by the processor causing the interrupt to be injected. > > Second, the IPI may be issued between kvm_x86_ops->sync_pir_to_irr(vcpu) > and vcpu->mode = IN_GUEST_MODE. In this case, kvm_vcpu_kick is called > but it (correctly) doesn't do anything because it sees vcpu->mode == > OUTSIDE_GUEST_MODE. Again, the guest is entered with PIR.ON but no > posted interrupt IPI is pending. This time, the fix for this is to move > the PIR->IRR synchronization and RVI update after setting IN_GUEST_MODE. > > Both issues were previously masked by the liberal usage of KVM_REQ_EVENT. > In both race scenarios KVM_REQ_EVENT would cancel guest entry, resulting > in another vmentry which would inject the interrupt. > > Signed-off-by: Paolo Bonzini > --- Reviewed-by: Radim Krčmář