Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4851160iob; Mon, 9 May 2022 03:10:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIT2plhCnrP7VXbVOcqVJzbf5n7aAdtQI32YekxB3a6L8jmXY8qxCEjUmw+sTbSBGSCdPp X-Received: by 2002:a17:902:b18e:b0:15f:b2c:6ca with SMTP id s14-20020a170902b18e00b0015f0b2c06camr5934218plr.84.1652091050298; Mon, 09 May 2022 03:10:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652091050; cv=none; d=google.com; s=arc-20160816; b=nIRreMH9/+L8zFhLt3uHnHgD75e1+L6jikqFYCreSGFze/LM5oIxTCh1Adadbjnonz U+QZA/uoEVVK92pw8Vi2bUDfvUKJ1zmA5fiq6v2Fl21HPpYTcRskOWp/Nh5957y5ccZ9 RrWkpA4W3tyfO29x4lHrkBjEBp28HTxW+Dz+y2kTlUmwwEqKIiTIaHrvRYyIkwb/hMzQ E2m02NyB6J8bjgsoSGEJm+s40C9c4p3Wf76fUkGE4MSiiRKgWTZCorGWgRRaXo8ik4Co 8bvuLymqUCTZnwZR4Yl/e0/ngN+o0eBlebhZHPwzqaeUNbrHrD/5acoH5OtlcGS26Jwc Pg3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ZM78wIZ6JLMPND7Ht3IA1Mgf/xPFUerHdSHdeZPHpFw=; b=ljcKcetvPt1TVzUQqpjogtatJYBWp8nY3PesZJ3ezim9ovnJhZIY2PSO+RRYym2wQT jDDgLLfNlBQqqyL4I+nXhaD9s6uFZ5eY6mRVwCSp9O+8LzfS0pyLEifQs4hA4SrNlPmd bxEIwjIdIFogZCasU0w60Ah53lDr0dDGGTeknnF5VjOo2m27TJEP7EO6A+d2wnXShpOf rayEDGvzkrTrr5Evfv7ovm6v0rEFa6KdxAXoFqfq/VmTBZAuXDOidaekTd6c+84rlPOs 98P1LfVqlQyMqt3zzUvaoBrm2GdNKQ0I+mn7ih4EA7QSUe5c+Ebb8ZRjlXqlVmXArj0e 7PHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b="Rkns/KQu"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id u16-20020a056a00159000b004fb83b0732dsi13262526pfk.323.2022.05.09.03.10.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 May 2022 03:10:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b="Rkns/KQu"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 705B6239B06; Mon, 9 May 2022 02:50:07 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233749AbiEIFoL (ORCPT + 99 others); Mon, 9 May 2022 01:44:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234512AbiEIFii (ORCPT ); Mon, 9 May 2022 01:38:38 -0400 Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CA668153F46 for ; Sun, 8 May 2022 22:34:45 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id c190-20020a1c35c7000000b0038e37907b5bso10119905wma.0 for ; Sun, 08 May 2022 22:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainfault-org.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZM78wIZ6JLMPND7Ht3IA1Mgf/xPFUerHdSHdeZPHpFw=; b=Rkns/KQugvEQmGsLLnfc60vj1l7V5wIkMGSPjxpCBigi+ckpY7MB9HM9yCG+ypQkhG pWxETVX5ZTxLiddk/JMOIIhnbLZH4vd805xOKIzmPBv5dkPeSEsmm5E//LXP8fQ2W1Es SiJKseZWMb4bbTNnDEm1aYChw5QX9PEO1kMgtH1SE09LD/28GI0WSAZG5cNQNKR1Q2JO GR+FtIOxEqsmcnM9AcbjvZ7a5VzK/sk0Lw43s5qVzf64RMfv13eCm35YG63rGQzJgXNa PZThzfS6C5Rdu8U1+I0gUfjyU4KtBflnnSicfKSMuSQzv8dhmPISS28YcMN9XJwEAbW0 CA1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZM78wIZ6JLMPND7Ht3IA1Mgf/xPFUerHdSHdeZPHpFw=; b=gqWIsesWue8ZwuIIqsWg5Ubv4iTiddIaSTEzPYc6PjJ2BBjuh0mO0yM9lnbmecFRIT kg5Lrv2Mtde4o94JJehRTY9XFkQ8KA92PKSYom0jJQzmYGa6rO16YWpH6CFsPzK5LHs8 /LpKI7gcSfgAO7n7oTWQ4u1wCjab/x8s2nLZuxYQOZaLqjM68UABRTCJ4dVvCol+VqK0 W+DQJsHMCcjMRn55BKa5Vx7OxeLVbmf34USfBDDoga7EWStu+6lti+zdA5ax5m3SYKeh fVSNtvV0eq9JZDeUJOBezGWVRI1+Msd0ZGUOWWfTVUPEEwOhUTOC/7Mw/UMieLQGvLIK tH5A== X-Gm-Message-State: AOAM530UxYBi1ArwwqR+80Lni8XlVZ3OZvR8/FnMMpOJiGyMfIpSoc9f AofgQ8AUtgTCMyrdxIQq+milwy2Y21iQIm9lTkSjiA== X-Received: by 2002:a05:600c:5113:b0:394:800c:4c36 with SMTP id o19-20020a05600c511300b00394800c4c36mr11044954wms.93.1652074484181; Sun, 08 May 2022 22:34:44 -0700 (PDT) MIME-Version: 1.0 References: <20220420112450.155624-1-apatel@ventanamicro.com> <20220420112450.155624-8-apatel@ventanamicro.com> In-Reply-To: From: Anup Patel Date: Mon, 9 May 2022 11:04:32 +0530 Message-ID: Subject: Re: [PATCH v2 7/7] RISC-V: KVM: Cleanup stale TLB entries when host CPU changes To: Atish Patra Cc: Anup Patel , Paolo Bonzini , Palmer Dabbelt , Paul Walmsley , Alistair Francis , KVM General , "open list:KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv)" , linux-riscv , "linux-kernel@vger.kernel.org List" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 6, 2022 at 1:23 PM Atish Patra wrote: > > On Wed, Apr 20, 2022 at 4:25 AM Anup Patel wrote: > > > > On RISC-V platforms with hardware VMID support, we share same > > VMID for all VCPUs of a particular Guest/VM. This means we might > > have stale G-stage TLB entries on the current Host CPU due to > > some other VCPU of the same Guest which ran previously on the > > current Host CPU. > > > > To cleanup stale TLB entries, we simply flush all G-stage TLB > > entries by VMID whenever underlying Host CPU changes for a VCPU. > > > > Signed-off-by: Anup Patel > > --- > > arch/riscv/include/asm/kvm_host.h | 5 +++++ > > arch/riscv/kvm/tlb.c | 23 +++++++++++++++++++++++ > > arch/riscv/kvm/vcpu.c | 11 +++++++++++ > > 3 files changed, 39 insertions(+) > > > > diff --git a/arch/riscv/include/asm/kvm_host.h b/arch/riscv/include/asm/kvm_host.h > > index a40e88a9481c..94349a5ffd34 100644 > > --- a/arch/riscv/include/asm/kvm_host.h > > +++ b/arch/riscv/include/asm/kvm_host.h > > @@ -166,6 +166,9 @@ struct kvm_vcpu_arch { > > /* VCPU ran at least once */ > > bool ran_atleast_once; > > > > + /* Last Host CPU on which Guest VCPU exited */ > > + int last_exit_cpu; > > + > > /* ISA feature bits (similar to MISA) */ > > unsigned long isa; > > > > @@ -256,6 +259,8 @@ void kvm_riscv_local_hfence_vvma_gva(unsigned long vmid, > > unsigned long order); > > void kvm_riscv_local_hfence_vvma_all(unsigned long vmid); > > > > +void kvm_riscv_local_tlb_sanitize(struct kvm_vcpu *vcpu); > > + > > void kvm_riscv_fence_i_process(struct kvm_vcpu *vcpu); > > void kvm_riscv_hfence_gvma_vmid_all_process(struct kvm_vcpu *vcpu); > > void kvm_riscv_hfence_vvma_all_process(struct kvm_vcpu *vcpu); > > diff --git a/arch/riscv/kvm/tlb.c b/arch/riscv/kvm/tlb.c > > index c0f86d09c41d..1a76d0b1907d 100644 > > --- a/arch/riscv/kvm/tlb.c > > +++ b/arch/riscv/kvm/tlb.c > > @@ -215,6 +215,29 @@ void kvm_riscv_local_hfence_vvma_all(unsigned long vmid) > > csr_write(CSR_HGATP, hgatp); > > } > > > > +void kvm_riscv_local_tlb_sanitize(struct kvm_vcpu *vcpu) > > +{ > > + unsigned long vmid; > > + > > + if (!kvm_riscv_gstage_vmid_bits() || > > + vcpu->arch.last_exit_cpu == vcpu->cpu) > > + return; > > + > > + /* > > + * On RISC-V platforms with hardware VMID support, we share same > > + * VMID for all VCPUs of a particular Guest/VM. This means we might > > + * have stale G-stage TLB entries on the current Host CPU due to > > + * some other VCPU of the same Guest which ran previously on the > > + * current Host CPU. > > + * > > + * To cleanup stale TLB entries, we simply flush all G-stage TLB > > + * entries by VMID whenever underlying Host CPU changes for a VCPU. > > + */ > > + > > + vmid = READ_ONCE(vcpu->kvm->arch.vmid.vmid); > > + kvm_riscv_local_hfence_gvma_vmid_all(vmid); > > +} > > + > > void kvm_riscv_fence_i_process(struct kvm_vcpu *vcpu) > > { > > local_flush_icache_all(); > > diff --git a/arch/riscv/kvm/vcpu.c b/arch/riscv/kvm/vcpu.c > > index 9cd8f6e91c98..a86710fcd2e0 100644 > > --- a/arch/riscv/kvm/vcpu.c > > +++ b/arch/riscv/kvm/vcpu.c > > @@ -67,6 +67,8 @@ static void kvm_riscv_reset_vcpu(struct kvm_vcpu *vcpu) > > if (loaded) > > kvm_arch_vcpu_put(vcpu); > > > > + vcpu->arch.last_exit_cpu = -1; > > + > > memcpy(csr, reset_csr, sizeof(*csr)); > > > > memcpy(cntx, reset_cntx, sizeof(*cntx)); > > @@ -735,6 +737,7 @@ static void noinstr kvm_riscv_vcpu_enter_exit(struct kvm_vcpu *vcpu) > > { > > guest_state_enter_irqoff(); > > __kvm_riscv_switch_to(&vcpu->arch); > > + vcpu->arch.last_exit_cpu = vcpu->cpu; > > guest_state_exit_irqoff(); > > } > > > > @@ -829,6 +832,14 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) > > continue; > > } > > > > + /* > > + * Cleanup stale TLB enteries > > + * > > + * Note: This should be done after G-stage VMID has been > > + * updated using kvm_riscv_gstage_vmid_ver_changed() > > + */ > > + kvm_riscv_local_tlb_sanitize(vcpu); > > + > > guest_timing_enter_irqoff(); > > > > kvm_riscv_vcpu_enter_exit(vcpu); > > -- > > 2.25.1 > > > > > Reviewed-by: Atish Patra Queued this patch for 5.19 Thanks, Anup > -- > Regards, > Atish