From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from Atcsqr.andestech.com (60-248-80-70.hinet-ip.hinet.net [60.248.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3829157487 for ; Thu, 9 Oct 2025 10:19:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=60.248.80.70 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760005192; cv=none; b=CxQsCzzshPEJ2AbFzAhv+s4FvFz3Veu7ZL+EqQYFT3SFjOVcFGLFn/Nrd4WFKN0e2XuDSzFGmXYlrECtJrlLHvhXyLjQdsK8RbQ3M39eOEqiHOJAOHggvbgJE+8uP64Hoj+jHJovJANgWols9BL+JhFT5IXc/AyvnLQ9+n5ZXTI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760005192; c=relaxed/simple; bh=ohtR0oYn448oPLiSFOjbSqDaVglh/DTDY7LpHa0tRdE=; h=Date:From:To:CC:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XTZaNsJaPyojxpq8tTCj4iHltSfY60Ax9l2cHfW9f88oq830iRthZj5ujlVzSkk/wsoXqloXdMBnwiC1+HqgWlwrKjbUmnSQwIV6mCFrCS/qktxs5uy6U5929YX/BhQmU/xJDFyfPkY9M3VpWrgpIpkNN66peL17E48nzeg2LB8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=permerror header.from=andestech.com; spf=pass smtp.mailfrom=andestech.com; arc=none smtp.client-ip=60.248.80.70 Authentication-Results: smtp.subspace.kernel.org; dmarc=permerror header.from=andestech.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=andestech.com Received: from mail.andestech.com (ATCPCS34.andestech.com [10.0.1.134]) by Atcsqr.andestech.com with ESMTPS id 599AFpSq031528 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Thu, 9 Oct 2025 18:15:51 +0800 (+08) (envelope-from ben717@andestech.com) Received: from atctrx.andestech.com (10.0.15.173) by ATCPCS34.andestech.com (10.0.1.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.39; Thu, 9 Oct 2025 18:15:51 +0800 Date: Thu, 9 Oct 2025 18:15:51 +0800 From: Ben Zong-You Xie To: Radim =?utf-8?B?S3LEjW3DocWZ?= CC: , , , , , , , , , , , , Hui Min Mina Chou , linux-riscv Subject: Re: [PATCH] RISC-V: KVM: flush VS-stage TLB after VCPU migration to prevent stale entries Message-ID: References: <20251002033402.610651-1-ben717@andestech.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/2.1.4 (2021-12-11) X-ClientProxiedBy: ATCPCS33.andestech.com (10.0.1.100) To ATCPCS34.andestech.com (10.0.1.134) X-DKIM-Results: atcpcs34.andestech.com; dkim=none; X-DNSRBL: X-SPAM-SOURCE-CHECK: pass X-MAIL:Atcsqr.andestech.com 599AFpSq031528 Hi Radim, Thanks for the review and the detailed comments. > What RISC-V implementation are you using? (And does the implementation > have the same memory access performance in V=0 and V=1 modes, even > though the latter has two levels of TLBs?) > The issue is found when validating our new AndesCore AX66. The address translation performance is the same for U and VU-mode when the uTLB is hit. > > To fix this, kvm_riscv_gstage_vmid_sanitize() is extended to flush both > > G-stage and VS-stage TLBs whenever a VCPU migrates to a different Host CPU. > > This ensures that no stale VS-stage mappings remain after VCPU migration. > > > > Fixes: b79bf2025dbc ("RISC-V: KVM: Rename and move kvm_riscv_local_tlb_sanitize()") > > b79bf2025dbc does not change behavior. > The bug must have been introduced earlier. > Will fix the incorrect Fixes tag in the next version. Thanks for pointing that out, we'll change to the following: Fixes: 92e450507d56 ("RISC-V: KVM: Cleanup stale TLB entries when host CPU changes") > > Signed-off-by: Hui Min Mina Chou > > Signed-off-by: Ben Zong-You Xie > > --- > > diff --git a/arch/riscv/kvm/vmid.c b/arch/riscv/kvm/vmid.c > > @@ -146,4 +146,10 @@ void kvm_riscv_gstage_vmid_sanitize(struct kvm_vcpu *vcpu) > > The function is now doing more that sanitizing gstage. > Maybe we can again call it kvm_riscv_local_tlb_sanitize()? > As for the naming, your suggestion makes sense. We’re also considering whether it should be moved back from vmid.c to tlb.c, and we’d like to hear other maintainers’ opinions before doing so. Thanks again for your feedback. Best regards, Ben