From patchwork Sun Nov 5 14:07:46 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Liran Alon X-Patchwork-Id: 10042197 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E67D96037D for ; Sun, 5 Nov 2017 14:08:19 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D62B628887 for ; Sun, 5 Nov 2017 14:08:19 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C954429382; Sun, 5 Nov 2017 14:08:19 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6A38C28887 for ; Sun, 5 Nov 2017 14:08:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751749AbdKEOIR (ORCPT ); Sun, 5 Nov 2017 09:08:17 -0500 Received: from userp1040.oracle.com ([156.151.31.81]:30911 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751699AbdKEOIQ (ORCPT ); Sun, 5 Nov 2017 09:08:16 -0500 Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id vA5E8Cpw014590 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 5 Nov 2017 14:08:12 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id vA5E8B0t032287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 5 Nov 2017 14:08:12 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vA5E8BXo024520; Sun, 5 Nov 2017 14:08:11 GMT Received: from liran-pc.ravello.local (/213.57.127.2) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 05 Nov 2017 06:08:10 -0800 From: Liran Alon To: pbonzini@redhat.com, rkrcmar@redhat.com, kvm@vger.kernel.org Cc: jmattson@google.com, idan.brown@oracle.com, Liran Alon , Konrad Rzeszutek Wilk Subject: [PATCH 4/4] KVM: nVMX: APICv: Always sync PIR to Virtual-APIC-Page on processing KVM_REQ_EVENT Date: Sun, 5 Nov 2017 16:07:46 +0200 Message-Id: <1509890866-8736-5-git-send-email-liran.alon@oracle.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1509890866-8736-1-git-send-email-liran.alon@oracle.com> References: <1509890866-8736-1-git-send-email-liran.alon@oracle.com> X-Source-IP: aserv0021.oracle.com [141.146.126.233] Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Consider the case L2 exits to L0 during event-delivery. In this case, vmx_complete_interrupts() will see IDT-vectoring-info is valid and therefore update KVM structs for event reinjection on next L2 resume. Assume that before L0 reaches vcpu_enter_guest(), another L1 CPU sends an IPI via virtual-posted-interrupts. That CPU will write a new vector to destination nested.pi_desc->pir and then will trigger an IPI with vector nested.posted_intr_nv. This will reach vmx_deliver_nested_posted_interrupt() which won't send a physical IPI (as vcpu->mode != IN_GUEST_MODE) but instead just signal nested.pi_pending=true and set KVM_REQ_EVENT. When destination CPU will reach vcpu_enter_guest(), it will consume the KVM_REQ_EVENT and call inject_pending_event() which will call check_nested_events(). However, because we have an event for reinjection to L2, vmx_check_nested_events() will return before calling vmx_complete_nested_posted_interrupt()! Therefore, not updating L1 virtual-apic-page and vmcs02's RVI. Assume that at this point we exit L2 and some L1 interrupt is raised afterwards (For example, another L1 CPU IPI). We will reach again vcpu_enter_guest() and call check_nested_events() that will exit from L2 to L1 due to pending interrupt and return from check_nested_events(). Again, without calling vmx_complete_nested_posted_interrupts()! At this point KVM_REQ_EVENT was already consumed and therefore cleared. When L1 will again VMRESUME into L2, it will run L2 without updated virtual-apic-page, with bad RVI and with PIR.ON set. Which is of course a bug... Fix this entire complex issue by just make vmx_check_nested_events() always call vmx_complete_nested_posted_interrupt(). Fixes: 705699a13994 ("KVM: nVMX: Enable nested posted interrupt processing") Signed-off-by: Liran Alon Reviewed-by: Nikita Leshenko Signed-off-by: Konrad Rzeszutek Wilk --- arch/x86/kvm/vmx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index c440df4a1604..d1981620c13a 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -11029,6 +11029,8 @@ static int vmx_check_nested_events(struct kvm_vcpu *vcpu, bool external_intr) bool block_nested_events = vmx->nested.nested_run_pending || kvm_event_needs_reinjection(vcpu); + vmx_complete_nested_posted_interrupt(vcpu); + if (vcpu->arch.exception.pending && nested_vmx_check_exception(vcpu, &exit_qual)) { if (block_nested_events) @@ -11069,7 +11071,6 @@ static int vmx_check_nested_events(struct kvm_vcpu *vcpu, bool external_intr) return 0; } - vmx_complete_nested_posted_interrupt(vcpu); return 0; }