All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Xie Bo" <xb@ultrarisc.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v4] RISC-V: KVM: Serialize virtual interrupt pending state updates
Date: Mon, 13 Jul 2026 07:47:14 +0000	[thread overview]
Message-ID: <20260713074714.80DA51F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260713073346.1293408-2-xb@ultrarisc.com>

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

Pre-existing issues:
- [High] Restoring guest `sip` (or `siph`) CSR via KVM_SET_ONE_REG drops pending interrupts from KVM's internal `irqs_pending` tracker, causing a vCPU stall if the guest executes WFI.
--

--- Patch [1]: [PATCH v4] RISC-V: KVM: Serialize virtual interrupt pending state updates ---
commit 445393d6bd22386cd7da7af1c9dd4c9d3be703a4
Author: Xie Bo <xb@ultrarisc.com>

RISC-V: KVM: Serialize virtual interrupt pending state updates

RISC-V KVM tracks guest interrupt state with two bitmaps: irqs_pending and
irqs_pending_mask. This commit serializes all updates to these bitmaps
with a per-vCPU raw spinlock to fix a race condition where injected
interrupts could be lost.

> diff --git a/arch/riscv/kvm/vcpu_onereg.c b/arch/riscv/kvm/vcpu_onereg.c
> index bb920e8923c93..cba3682944b69 100644
> --- a/arch/riscv/kvm/vcpu_onereg.c
> +++ b/arch/riscv/kvm/vcpu_onereg.c
[ ... ]
> @@ -309,10 +310,14 @@ static int kvm_riscv_vcpu_general_set_csr(struct kvm_vcpu *vcpu,
>  		reg_val <<= VSIP_TO_HVIP_SHIFT;
>  	}
>  
> -	((unsigned long *)csr)[reg_num] = reg_val;
> -
> -	if (reg_num == KVM_REG_RISCV_CSR_REG(sip))
> -		WRITE_ONCE(vcpu->arch.irqs_pending_mask[0], 0);
> +	if (reg_num == KVM_REG_RISCV_CSR_REG(sip)) {
> +		raw_spin_lock_irqsave(&vcpu->arch.irqs_pending_lock, flags);
> +		((unsigned long *)csr)[reg_num] = reg_val;
> +		vcpu->arch.irqs_pending_mask[0] = 0;

[Severity: High]
This is a pre-existing issue, but does restoring the guest sip (or siph)
CSR via KVM_SET_ONE_REG drop pending interrupts from KVM's internal
irqs_pending tracker?

If userspace (e.g., QEMU) migrating a VM writes to KVM_REG_RISCV_CSR_REG(sip),
csr->hvip is updated and irqs_pending_mask[0] is cleared. However,
irqs_pending[0] is not updated with the restored state.

Later, if the guest executes WFI with interrupts locally disabled but
globally expected to wake it, kvm_riscv_vcpu_has_interrupts() will return
false because it solely checks irqs_pending:

arch/riscv/kvm/vcpu.c:kvm_riscv_vcpu_has_interrupts() {
    ...
	ret = vcpu->arch.irqs_pending[0] & ie;
    ...
}

Could this cause a VM hang or stalled vCPU after live migration if it enters
WFI?

> +		raw_spin_unlock_irqrestore(&vcpu->arch.irqs_pending_lock, flags);
> +	} else {
> +		((unsigned long *)csr)[reg_num] = reg_val;
> +	}
>  
>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260713073346.1293408-2-xb@ultrarisc.com?part=1

  reply	other threads:[~2026-07-13  7:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16  6:17 [PATCH] RISC-V: KVM: Fix lost virtual interrupts during IRQ sync Xie Bo
2026-06-16  6:17 ` Xie Bo
2026-06-16  6:17 ` Xie Bo
2026-07-07  8:27 ` 谢波
2026-07-07  8:27   ` 谢波
2026-07-07  8:27   ` 谢波
2026-07-13  4:43 ` Anup Patel
2026-07-13  4:43   ` Anup Patel
2026-07-13  4:43   ` Anup Patel
2026-07-13  6:48   ` Xie Bo
2026-07-13  6:48     ` Xie Bo
2026-07-13  6:48     ` Xie Bo
2026-07-13  6:48     ` [PATCH v3] RISC-V: KVM: Serialize virtual interrupt pending state updates Xie Bo
2026-07-13  6:48       ` Xie Bo
2026-07-13  6:48       ` Xie Bo
2026-07-13  7:06       ` sashiko-bot
2026-07-13  7:33   ` [PATCH] RISC-V: KVM: Fix lost virtual interrupts during IRQ sync Xie Bo
2026-07-13  7:33     ` Xie Bo
2026-07-13  7:33     ` Xie Bo
2026-07-13  7:33     ` [PATCH v4] RISC-V: KVM: Serialize virtual interrupt pending state updates Xie Bo
2026-07-13  7:33       ` Xie Bo
2026-07-13  7:33       ` Xie Bo
2026-07-13  7:47       ` sashiko-bot [this message]
2026-07-14 12:47       ` Anup Patel
2026-07-14 12:47         ` Anup Patel
2026-07-14 12:47         ` Anup Patel

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=20260713074714.80DA51F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=xb@ultrarisc.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.