All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Carlos López" <clopez@suse.de>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: VMX: Raise KVM_REQ_EVENT on TPR below threshold exit
Date: Wed, 10 Jun 2026 19:10:05 +0000	[thread overview]
Message-ID: <20260610191005.93F731F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260610185042.2810880-2-clopez@suse.de>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The patch successfully fixes the VM entry failure for hardware-induced TPR_BELOW_THRESHOLD exits but leaves the exact same vulnerability in software-emulated TPR writes (MMIO, MSR, or intercepted CR8 writes). If the guest lowers TPR such that VTPR falls below TPR_THRESHOLD, but PPR does not drop enough to unmask a pending interrupt (e.g., due to a higher-priority ISR), `apic_update_ppr()` will not raise KVM_REQ_EVENT. Consequently, `kvm_lapic_update_cr8_intercept()` is skipped, leaving a stale TPR_THRESHOLD in the VMCS that is strictly greater than VTPR[7:4]. On hardware without virtual-interrupt delivery, this directly violates SDM VM-entry constraints, causing the exact same hardware error 0x7 VM entry failure the patch was intended to fix.
--

commit 277f13148f7967e36731fd691e61fdaf6d48f638
Author: Carlos López <clopez@suse.de>

KVM: VMX: Raise KVM_REQ_EVENT on TPR below threshold exit

This commit fixes a VM entry failure with hardware error 0x7 on older
platforms or under nested virtualization by re-introducing an unconditional
KVM_REQ_EVENT when handling TPR-below-threshold exits. This ensures that
vmx_update_cr8_intercept() is called to re-evaluate TPR_THRESHOLD.

Link: https://github.com/coconut-svsm/svsm/issues/1081 [1]

> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index c548f22375ad6..21a469d3ba211 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -5824,6 +5824,7 @@ void vmx_set_dr7(struct kvm_vcpu *vcpu, unsigned long val)
>  static int handle_tpr_below_threshold(struct kvm_vcpu *vcpu)
>  {
>  	kvm_apic_update_ppr(vcpu);
> +	kvm_make_request(KVM_REQ_EVENT, vcpu);

[Severity: High]
This isn't a bug introduced by this patch, but does the same regression
still exist in the software-emulated TPR write paths?

Looking at apic_set_tpr() in arch/x86/kvm/lapic.c:

static void apic_set_tpr(struct kvm_lapic *apic, u32 tpr)
{
        kvm_lapic_set_reg(apic, APIC_TASKPRI, tpr);
        apic_update_ppr(apic);
}

If the guest lowers the TPR via MMIO, MSR, or an intercepted CR8 write such
that VTPR falls below TPR_THRESHOLD, but the PPR does not drop enough to
unmask a pending interrupt, apic_update_ppr() will not raise KVM_REQ_EVENT.

Consequently, kvm_lapic_update_cr8_intercept() would be skipped, leaving a
stale TPR_THRESHOLD in the VMCS that is strictly greater than VTPR[7:4].

Could this lead to the exact same hardware error 0x7 VM entry failure that
this patch aims to fix?

>  	return 1;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610185042.2810880-2-clopez@suse.de?part=1

  reply	other threads:[~2026-06-10 19:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-10 18:50 [PATCH] KVM: VMX: Raise KVM_REQ_EVENT on TPR below threshold exit Carlos López
2026-06-10 19:10 ` sashiko-bot [this message]
2026-06-10 19:11 ` Sean Christopherson
2026-06-10 21:09   ` Carlos López

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260610191005.93F731F00893@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=clopez@suse.de \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.