All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Sean Christopherson" <seanjc@google.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev,
	"Oliver Upton" <oupton@kernel.org>,
	"Marc Zyngier" <maz@kernel.org>
Subject: Re: [PATCH] KVM: Never clear KVM_REQ_VM_DEAD from a vCPU's requests
Date: Thu, 06 Aug 2026 22:08:56 +0000	[thread overview]
Message-ID: <20260806220856.D7A3B1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806214618.82180-1-seanjc@google.com>

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

Pre-existing issues:
- [High] Unhandled KVM_REQ_VM_DEAD across multiple architectures (s390, RISC-V, PowerPC, LoongArch) causes dead VMs to either improperly resume guest execution or get stuck in an infinite kernel loop.
--

--- Patch [1]: [PATCH] KVM: Never clear KVM_REQ_VM_DEAD from a vCPU's requests ---
commit c8b0ec7047292dc9b84167da2e2a4d9abf600813
Author: Sean Christopherson <seanjc@google.com>

KVM: Never clear KVM_REQ_VM_DEAD from a vCPU's requests

This commit modifies KVM_REQ_VM_DEAD checks to use kvm_test_request()
instead of kvm_check_request(), ensuring the flag is never cleared. It
also adds a build-time assertion to guard against clearing it via standard
APIs.

> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 03bfc92864b6e..cf7fe835c4ad2 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -2324,13 +2324,18 @@ static inline bool kvm_test_request(int req, struct kvm_vcpu *vcpu)
>  	return test_bit(req & KVM_REQUEST_MASK, (void *)&vcpu->requests);
>  }
>  
> -static inline void kvm_clear_request(int req, struct kvm_vcpu *vcpu)
> +static __always_inline void kvm_clear_request(int req, struct kvm_vcpu *vcpu)
>  {
> +	BUILD_BUG_ON(req == KVM_REQ_VM_DEAD);
> +
>  	clear_bit(req & KVM_REQUEST_MASK, (void *)&vcpu->requests);
>  }
>  
> -static inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu)
> +static __always_inline bool kvm_check_request(int req, struct kvm_vcpu *vcpu)
>  {
> +	/* Once a VM is dead, it needs to stay dead. */
> +	BUILD_BUG_ON(req == KVM_REQ_VM_DEAD);
> +

[Severity: High]
This is a pre-existing issue, but while tightening the KVM_REQ_VM_DEAD API,
should this request be explicitly handled on other architectures?

Currently, s390, RISC-V, PowerPC, and LoongArch do not check for
KVM_REQ_VM_DEAD in their request handling loops. Because the flag is never
handled, kvm_request_pending() remains permanently true when a VM is marked
dead (e.g., via KVM_BUG_ON() in common pfncache or MMIO paths).

Could this cause the vCPU run loops to infinitely spin inside the kernel
without returning to userspace? For example:
- arch/riscv/kvm/vcpu.c:kvm_riscv_check_vcpu_requests()
- arch/powerpc/kvm/powerpc.c:kvm_arch_vcpu_ioctl_run() calling
  kvmppc_core_check_requests()
- arch/loongarch/kvm/vcpu.c:kvm_check_requests() inside kvm_pre_enter_guest()

Additionally, for s390:
- arch/s390/kvm/kvm-s390.c:kvm_s390_handle_requests() returns 0 when no
  other requests are handled. Can this cause the dead VM to improperly
  resume guest execution via sie64a() with a broken host state?

>  	if (kvm_test_request(req, vcpu)) {
>  		kvm_clear_request(req, vcpu);
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806214618.82180-1-seanjc@google.com?part=1

  reply	other threads:[~2026-08-06 22:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-06 21:46 [PATCH] KVM: Never clear KVM_REQ_VM_DEAD from a vCPU's requests Sean Christopherson
2026-08-06 22:08 ` sashiko-bot [this message]
2026-08-07  8:20 ` Marc Zyngier
2026-08-10  1:29 ` Huang, Kai

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=20260806220856.D7A3B1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=seanjc@google.com \
    /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.