From: Guo Ren <guoren@kernel.org>
To: fangyu.yu@linux.alibaba.com
Cc: anup@brainfault.org, atish.patra@linux.dev, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
liujingqi@lanxincomputing.com, kvm@vger.kernel.org,
kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RISC-V: KVM: Read HGEIP CSR on the correct cpu
Date: Thu, 16 Oct 2025 15:09:18 +0800 [thread overview]
Message-ID: <CAJF2gTQLkddb-eGhkMSOBib9_fMt1Loo9aoR2tH-kVdekQdQzQ@mail.gmail.com> (raw)
In-Reply-To: <20251016012659.82998-1-fangyu.yu@linux.alibaba.com>
On Thu, Oct 16, 2025 at 9:27 AM <fangyu.yu@linux.alibaba.com> wrote:
>
> From: Fangyu Yu <fangyu.yu@linux.alibaba.com>
>
> When executing kvm_riscv_vcpu_aia_has_interrupts, the vCPU may have
> migrated and the IMSIC VS-file have not been updated yet, currently
> the HGEIP CSR should be read from the imsic->vsfile_cpu ( the pCPU
> before migration ) via on_each_cpu_mask, but this will trigger an
> IPI call and repeated IPI within a period of time is expensive in
> a many-core systems.
>
> Just let the vCPU execute and update the correct IMSIC VS-file via
> kvm_riscv_vcpu_aia_imsic_update may be a simple solution.
>
> Fixes: 4cec89db80ba ("RISC-V: KVM: Move HGEI[E|P] CSR access to IMSIC virtualization")
> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com>
> ---
> arch/riscv/kvm/aia_imsic.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/kvm/aia_imsic.c b/arch/riscv/kvm/aia_imsic.c
> index fda0346f0ea1..168c02ad0a78 100644
> --- a/arch/riscv/kvm/aia_imsic.c
> +++ b/arch/riscv/kvm/aia_imsic.c
> @@ -689,8 +689,12 @@ bool kvm_riscv_vcpu_aia_imsic_has_interrupt(struct kvm_vcpu *vcpu)
> */
>
> read_lock_irqsave(&imsic->vsfile_lock, flags);
> - if (imsic->vsfile_cpu > -1)
> - ret = !!(csr_read(CSR_HGEIP) & BIT(imsic->vsfile_hgei));
> + if (imsic->vsfile_cpu > -1) {
> + if (imsic->vsfile_cpu != smp_processor_id())
Why not if (imsic->vsfile_cpu != vcpu->cpu)?
if pcpu changed, the kvm_sched_in() would update "vcpu->cpu by
raw_smp_processor_id()".
The smp_processor_id() may involve DEBUG_PREEMPT code, and
check_preemption_disabled() may cause a problem? Anyway, a full
smp_processor_id() is not needed here, vcpu->cpu is enough.
If (imsic->vsfile_cpu != vcpu->cpu), then:
Reviewed-by: Guo Ren <guoren@kernel.org>
> + ret = true;
Agree!
When a vCPU migrates to another pCPU, we could assume the interrupt
has come in to prevent the missing interrupt.
To illustrate why ret = true, consider this example:
1. Guest WFI VM_exit.
2. Host Trap -> kvm_riscv_vcpu_exit() -> kvm_riscv_vcpu_virtual_insn()
->kvm_vcpu_halt() ->
kvm_vcpu_check_block() -> kvm_riscv_vcpu_aia_imsic_has_interrupt() loop:
for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
if (kvm_vcpu_check_block(vcpu) < 0)
break;
waited = true;
schedule(); // if pcpu changed, the kvm_sched_in()
would update "vcpu->cpu = raw_smp_processor_id()".
}
3. Back to the outer loop in kvm/vcpu.c:
while (ret > 0) {
/* Check conditions before entering the guest */
ret = xfer_to_guest_mode_handle_work(vcpu);
if (ret)
continue;
ret = 1;
kvm_riscv_gstage_vmid_update(vcpu);
kvm_riscv_check_vcpu_requests(vcpu);
preempt_disable();
/* Update AIA HW state before entering guest */
ret = kvm_riscv_vcpu_aia_update(vcpu); // Update
imsic->vsfile_cpu with vcpu->cpu;
4. VM_enter Guest WFI
If there are no changes, then Guest WFI VM_exit again.
5. Host Trap again, but the vsfile_cpu & vcpu->cpu &
raw_smp_processor_id() are synchronized.
> + else
> + ret = !!(csr_read(CSR_HGEIP) & BIT(imsic->vsfile_hgei));
> + }
> read_unlock_irqrestore(&imsic->vsfile_lock, flags);
>
> return ret;
> --
> 2.50.1
>
--
Best Regards
Guo Ren
next prev parent reply other threads:[~2025-10-16 7:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-16 1:26 fangyu.yu
2025-10-16 7:09 ` Guo Ren [this message]
2025-10-17 6:58 ` Anup Patel
2025-10-17 9:53 ` Guo Ren
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=CAJF2gTQLkddb-eGhkMSOBib9_fMt1Loo9aoR2tH-kVdekQdQzQ@mail.gmail.com \
--to=guoren@kernel.org \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@linux.dev \
--cc=fangyu.yu@linux.alibaba.com \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=liujingqi@lanxincomputing.com \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®