Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 12 Sep 2022 10:26:00 +0300
From:   Sergey Matyukevich <geomatsi@gmail.com>
To:     Jinyu Tang <tjytimi@163.com>
Cc:     anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com,
        aou@eecs.berkeley.edu, alexandre.ghiti@canonical.com,
        guoren@kernel.org, heiko@sntech.de, akpm@linux-foundation.org,
        panqinglin2020@iscas.ac.cn, tongtiangen@huawei.com,
        sunnanyong@huawei.com, anshuman.khandual@arm.com,
        atishp@rivosinc.com, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org, falcon@tinylab.org
Subject: Re: [PATCH v2] riscv: make update_mmu_cache to support asid
Message-ID: <Yx7fCL3rMgT4Uh96@curiosity>
References: <20220904133710.117263-1-tjytimi@163.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220904133710.117263-1-tjytimi@163.com>
Precedence: bulk

Hi Jinyu,

> The `update_mmu_cache` function in riscv flush tlb cache without asid
> information now, which will flush tlbs in other tasks' address space
> even if processor supports asid. So add a new function
> `flush_tlb_local_one_page` to flush local one page whether processor
> supports asid or not,for cases that need to flush local one page like
> function `update_mmu_cache`.
> 
> Signed-off-by: Jinyu Tang <tjytimi@163.com>
> ---
> RFC V1 -> V2 : 
> 1.Rebased on PATCH9 of IPI imporvement series as Anup Patel
> suggestion. 
> 2.Make commit log more clear.
> 
>  arch/riscv/include/asm/pgtable.h  |  2 +-
>  arch/riscv/include/asm/tlbflush.h |  2 ++
>  arch/riscv/mm/tlbflush.c          | 11 +++++++++++
>  3 files changed, 14 insertions(+), 1 deletion(-)

Just FYI: I have been looking into the same function w.r.t. to its
ASID/SMP handling. In addition to what your patch is doing with ASID,
I posted experimental change following flush_icache_mm approach. That
patch takes into account other concurrently running harts as well as
possible migration to other harts later on, see:

https://lore.kernel.org/linux-riscv/20220829205219.283543-1-geomatsi@gmail.com/

Regards,
Sergey