From: sashiko-bot@kernel.org
To: "Bibo Mao" <maobibo@loongson.cn>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH v2 3/5] LoongArch: KVM: Add separate vmid feature support
Date: Thu, 06 Aug 2026 02:30:59 +0000 [thread overview]
Message-ID: <20260806023100.61F791F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260806020739.2149268-4-maobibo@loongson.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The patch introduces `if (!cpu_has_guestid)` feature gates to bypass existing VPID and TLB flush mechanisms, but completely omits the alternative logic for when the feature is enabled, introducing severe latent vulnerabilities (broken VM isolation, skipped TLB flushes).
--
--- Patch [3]: [PATCH v2 3/5] LoongArch: KVM: Add separate vmid feature support ---
commit 6bfee108dace797d9e6015bf026032adaef591e9
Author: Bibo Mao <maobibo@loongson.cn>
LoongArch: KVM: Add separate vmid feature support
Feature cpu_has_guestid is used to check whether separate vmid/vpid
is supported or not. It is disabled by default, add this feature
checking, there is no function change.
> diff --git a/arch/loongarch/kvm/main.c b/arch/loongarch/kvm/main.c
> index ac804e77e844f..c36e62ab0d917 100644
> --- a/arch/loongarch/kvm/main.c
> +++ b/arch/loongarch/kvm/main.c
> @@ -218,7 +218,8 @@ static void kvm_update_vpid(struct kvm_vcpu *vcpu, int cpu)
> ++vpid; /* vpid 0 reserved for root */
>
> /* start new vpid cycle */
> - kvm_flush_tlb_all();
> + if (!cpu_has_guestid)
> + kvm_flush_tlb_all();
[Severity: Critical]
If cpu_has_guestid is true, this skips the global TLB flush on VPID
wrap-around. Is there an alternative flush mechanism that should be
implemented here when the feature is enabled?
> }
>
> context->vpid_cache = vpid;
> @@ -282,10 +283,13 @@ static void __kvm_check_vmid(struct kvm_vcpu *vcpu)
> {
> unsigned long vmid;
>
> - vmid = vcpu->arch.vpid & vpid_mask;
> - if (vcpu->arch.hw_vmid != vmid) {
> - vcpu->arch.hw_vmid = vcpu->arch.vpid & vpid_mask;
> - kvm_clear_request(KVM_REQ_TLB_FLUSH_GPA, vcpu);
> + /* On some machines like 3A5000, vmid needs the same with vpid */
> + if (!cpu_has_guestid) {
> + vmid = vcpu->arch.vpid & vpid_mask;
> + if (vcpu->arch.hw_vmid != vmid) {
> + vcpu->arch.hw_vmid = vcpu->arch.vpid & vpid_mask;
> + kvm_clear_request(KVM_REQ_TLB_FLUSH_GPA, vcpu);
> + }
> }
> }
[Severity: Critical]
When cpu_has_guestid is true, the hw_vmid update is skipped entirely without
alternative logic, leaving hw_vmid uninitialized (0).
When kvm_switch_to_guest() in arch/loongarch/kvm/switch.S loads hw_vmid into
the hardware Guest ID register (LOONGARCH_CSR_GTLBC), will all VMs share
VMID 0, breaking stage-2 VM isolation?
> diff --git a/arch/loongarch/kvm/mmu.c b/arch/loongarch/kvm/mmu.c
> index e104897aa5328..714640a2e6142 100644
> --- a/arch/loongarch/kvm/mmu.c
> +++ b/arch/loongarch/kvm/mmu.c
> @@ -929,8 +929,10 @@ int kvm_handle_mm_fault(struct kvm_vcpu *vcpu, unsigned long gpa, bool write, in
> *
> * With SW PTW, invalid TLB is added in TLB refill exception.
> */
> - vcpu->arch.flush_gpa = gpa;
> - kvm_make_request(KVM_REQ_TLB_FLUSH_GPA, vcpu);
> + if (!cpu_has_guestid) {
> + vcpu->arch.flush_gpa = gpa;
> + kvm_make_request(KVM_REQ_TLB_FLUSH_GPA, vcpu);
> + }
> }
>
> return 0;
[Severity: Critical]
Are we missing a TLB flush request for stale translation entries when
cpu_has_guestid is enabled?
> diff --git a/arch/loongarch/kvm/vcpu.c b/arch/loongarch/kvm/vcpu.c
> index 20c207d80e31a..0b2355aec9322 100644
> --- a/arch/loongarch/kvm/vcpu.c
> +++ b/arch/loongarch/kvm/vcpu.c
> @@ -210,7 +210,8 @@ 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 */
> + if (!cpu_has_guestid)
> + vcpu->arch.vpid = 0; /* Drop vpid for this vCPU */
>
> if (kvm_dirty_ring_check_request(vcpu))
> return RESUME_HOST;
[Severity: Critical]
This consumes the KVM_REQ_TLB_FLUSH request but skips dropping the VPID when
cpu_has_guestid is true. Could this effectively swallow the request without
performing the actual flush logic?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260806020739.2149268-1-maobibo@loongson.cn?part=3
next prev parent reply other threads:[~2026-08-06 2:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 2:07 [PATCH v2 0/5] LoongArch: KVM: Add separate vmid support Bibo Mao
2026-08-06 2:07 ` [PATCH v2 1/5] LoongArch: KVM: Add vmid support for stage2 MMU Bibo Mao
2026-08-06 12:20 ` Huacai Chen
2026-08-06 12:39 ` Bibo Mao
2026-08-06 2:07 ` [PATCH v2 2/5] LoongArch: KVM: Add separate vCPU and VM id update function Bibo Mao
2026-08-06 2:07 ` [PATCH v2 3/5] LoongArch: KVM: Add separate vmid feature support Bibo Mao
2026-08-06 2:30 ` sashiko-bot [this message]
2026-08-06 12:23 ` Huacai Chen
2026-08-06 12:41 ` Bibo Mao
2026-08-06 2:07 ` [PATCH v2 4/5] LoongArch: KVM: Implement vmid updating logic Bibo Mao
2026-08-06 2:30 ` sashiko-bot
2026-08-06 3:00 ` Bibo Mao
2026-08-06 2:07 ` [PATCH v2 5/5] LoongArch: KVM: Enable separate vmid feature Bibo Mao
2026-08-06 2:47 ` sashiko-bot
2026-08-06 12:39 ` Huacai Chen
2026-08-06 12:55 ` Bibo Mao
2026-08-06 13:03 ` Huacai Chen
2026-08-07 1:10 ` Bibo Mao
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=20260806023100.61F791F000E9@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox