From patchwork Mon Jan 18 23:02:32 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Ruffell X-Patchwork-Id: 1428331 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4DKS486TSnz9sWT; Tue, 19 Jan 2021 10:02:48 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1l1dXq-0005m9-6e; Mon, 18 Jan 2021 23:02:46 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1l1dXn-0005lB-20 for kernel-team@lists.ubuntu.com; Mon, 18 Jan 2021 23:02:43 +0000 Received: from mail-pj1-f69.google.com ([209.85.216.69]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1l1dXm-0003qe-MB for kernel-team@lists.ubuntu.com; Mon, 18 Jan 2021 23:02:42 +0000 Received: by mail-pj1-f69.google.com with SMTP id q10so15024490pjg.1 for ; Mon, 18 Jan 2021 15:02:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=kMM1YPm1fE2pi5go5TtTOqedKA9VlI4gYCH0nJToSQM=; b=gvaOpmm2xMJrMYrcI0rU2bcyVItMOKrGMj3QjATRAswuB6yAl4o+7v+DHERgcIsZg1 jiyD64pYpIMZ1Gq4BvIYhOIgMJ6chaCBP73wU7YZ2weQUuX5Asb7ChKEv7swuhMbmiLt u0QAYf7rhgd8Kn4Gwe4qfS3k4Bm+5k3aSwtPKFhgCU35i2QcGjcEgdv3d2qa8HWuh2Tj wrNwtuzsX/H1gbkO2oO+6L5oGoiwDDUFvkLmT9AExNJtPv+Y3AlgaDTflU4pxHX9qXgA MzUBGegOunLuxn7F0a53RIMu0IsCJCUxh6sPYdME8FT8RsOYmQanf2drY8/4NofroA3M h2CA== X-Gm-Message-State: AOAM5316dpDwYx/yh09Pc2CwhMzBu4fYz8yYEhyGLkTnCFWH93K4I31i iJLSSu5XJD3NsU3KJJ43omwwodlrda+DqX/0kWDLy8skQOLlgvbd9qiK16wunf5Pn3VD/9C2Yzx AitpOBfUsN6YRIyAiRDaCxJFgXCX5d0HslNSgk0o97Q== X-Received: by 2002:a63:4d59:: with SMTP id n25mr1722692pgl.122.1611010961402; Mon, 18 Jan 2021 15:02:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJyoqEJSI8N6SeCNMkxHAheJZSclC/6O2PPZ3VAKRI+xrPetEcVS3lOqwxXwDts3iYLSUTdyxQ== X-Received: by 2002:a63:4d59:: with SMTP id n25mr1722674pgl.122.1611010961089; Mon, 18 Jan 2021 15:02:41 -0800 (PST) Received: from localhost.localdomain (222-152-178-139-fibre.sparkbb.co.nz. [222.152.178.139]) by smtp.gmail.com with ESMTPSA id 92sm443515pjv.15.2021.01.18.15.02.39 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Jan 2021 15:02:40 -0800 (PST) From: Matthew Ruffell To: kernel-team@lists.ubuntu.com Subject: [SRU][Focal][PATCH 1/1] KVM: x86: Set KVM_REQ_EVENT if run is canceled with req_immediate_exit set Date: Tue, 19 Jan 2021 12:02:32 +1300 Message-Id: <20210118230232.32247-2-matthew.ruffell@canonical.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20210118230232.32247-1-matthew.ruffell@canonical.com> References: <20210118230232.32247-1-matthew.ruffell@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Sean Christopherson BugLink: https://bugs.launchpad.net/bugs/1911848 Re-request KVM_REQ_EVENT if vcpu_enter_guest() bails after processing pending requests and an immediate exit was requested. This fixes a bug where a pending event, e.g. VMX preemption timer, is delayed and/or lost if the exit was deferred due to something other than a higher priority _injected_ event, e.g. due to a pending nested VM-Enter. This bug only affects the !injected case as kvm_x86_ops.cancel_injection() sets KVM_REQ_EVENT to redo the injection, but that's purely serendipitous behavior with respect to the deferred event. Note, emulated preemption timer isn't the only event that can be affected, it simply happens to be the only event where not re-requesting KVM_REQ_EVENT is blatantly visible to the guest. Fixes: f4124500c2c13 ("KVM: nVMX: Fully emulate preemption timer") Signed-off-by: Sean Christopherson Message-Id: <20200423022550.15113-4-sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini (backported from commit 8081ad06b68a728e676d3b08e9ab70ce4039747b) [mruffell: minor context adjustment] Signed-off-by: Matthew Ruffell Acked-by: Stefan Bader --- arch/x86/kvm/x86.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index e519e0af028a..dddbeb3ee2c6 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -8345,6 +8345,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu) return r; cancel_injection: + if (req_immediate_exit) + kvm_make_request(KVM_REQ_EVENT, vcpu); kvm_x86_ops->cancel_injection(vcpu); if (unlikely(vcpu->arch.apic_attention)) kvm_lapic_sync_from_vapic(vcpu);