All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Bibo Mao" <maobibo@loongson.cn>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH 5/6] LoongArch: KVM: Add remote tlb flushing support
Date: Mon, 27 Jul 2026 07:46:02 +0000	[thread overview]
Message-ID: <20260727074602.C9F9E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260727072109.2151675-6-maobibo@loongson.cn>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Local TLB flush requests via KVM_REQ_TLB_FLUSH are silently ignored when cpu_has_guestid is true.
--

--- Patch [5]: [PATCH 5/6] LoongArch: KVM: Add remote tlb flushing support ---
commit 8224c08441c8eee94923d3771b8015f38a7278ab
Author: Bibo Mao <maobibo@loongson.cn>

LoongArch: KVM: Add remote tlb flushing support

This commit introduces remote TLB flushing support by queueing a TLB
invalidation for each CPU to perform on the next vCPU load. It adds a
tlb_flush_pending cpumask and updates the vmid index when scheduled on
a physical CPU, while keeping the vpid index unchanged.

[ ... ]

> diff --git a/arch/loongarch/kvm/vcpu.c b/arch/loongarch/kvm/vcpu.c
> index 20c207d80e31a..19c81ae8941a9 100644
> --- a/arch/loongarch/kvm/vcpu.c
> +++ b/arch/loongarch/kvm/vcpu.c
> @@ -210,7 +210,12 @@ static int kvm_check_requests(struct kvm_vcpu *vcpu)
>  		return RESUME_GUEST;
>  
>  	if (kvm_check_request(KVM_REQ_TLB_FLUSH, vcpu))
> -		vcpu->arch.vpid = 0;  /* Drop vpid for this vCPU */
> +		/*
> +		 * vpid need the same with vmid if vpid is not separated
> +		 * with vmid
> +		 */
> +		if (!cpu_has_guestid)
> +			vcpu->arch.vpid = 0;  /* Drop vpid for this vCPU */

[Severity: High]
Does this silently ignore local TLB flush requests when cpu_has_guestid is
true?

If a local KVM_REQ_TLB_FLUSH is made, for example by kvm_map_page() in
arch/loongarch/kvm/mmu.c when upgrading to a huge page, kvm_check_request()
will clear the request bit here.

However, if cpu_has_guestid is true, the VPID is not dropped. Because this
is a local flush, the tlb_flush_pending cpumask is not set globally, meaning
kvm_check_vmid() will not drop the VMID either.

Will this cause the local TLB flush to be completely lost, potentially
leading to an infinite page fault loop if the guest hits a stale invalid
TLB entry on hardware with a page table walker?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727072109.2151675-1-maobibo@loongson.cn?part=5

  reply	other threads:[~2026-07-27  7:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27  7:21 [PATCH 0/6] LoongArch: KVM: Add separate vmid support Bibo Mao
2026-07-27  7:21 ` [PATCH 1/6] LoongArch: KVM: Add vmid support for stage2 MMU Bibo Mao
2026-07-27  7:21 ` [PATCH 2/6] LoongArch: KVM: Add separate vCPU and VM id update function Bibo Mao
2026-07-27  7:21 ` [PATCH 3/6] LoongArch: KVM: Add separate vmid feature support Bibo Mao
2026-07-27  7:42   ` sashiko-bot
2026-07-27  7:21 ` [PATCH 4/6] LoongArch: KVM: implement vmid updating logic Bibo Mao
2026-07-27  7:49   ` sashiko-bot
2026-07-27  7:21 ` [PATCH 5/6] LoongArch: KVM: Add remote tlb flushing support Bibo Mao
2026-07-27  7:46   ` sashiko-bot [this message]
2026-07-27  7:21 ` [PATCH 6/6] LoongArch: KVM: Enable separate vmid feature Bibo Mao
2026-07-27  7:40   ` sashiko-bot

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=20260727074602.C9F9E1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=maobibo@loongson.cn \
    --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.