Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp2100398pxb; Sat, 22 Jan 2022 16:16:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJyCk/MgMG6ny5s2/x0QCmbV1rbULbUXt3uKTPTqwZc4Oq85Wtp4kJXlmeBnUm0OGslzkOf5 X-Received: by 2002:a17:902:f291:b0:14a:ff45:b164 with SMTP id k17-20020a170902f29100b0014aff45b164mr9215086plc.47.1642896983912; Sat, 22 Jan 2022 16:16:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642896983; cv=none; d=google.com; s=arc-20160816; b=y8PgsQx7wB8U2V1l21pPdlnuEWDjiEUxZoNFdYoeULR3GakoeqNuX9vAMJSnCgBSgu 9YvYvzqf6lAf+jt9iZjELTA4vbPv1DzgJmTAq/NhnqVKUUt+D+RS2XUqCv1ZGxP7AMLn 5MN2Q+HMTc8df8JDEfkwvlxjkuqccXcEwA4vkYAkeDpCPNzxJqjm66ADMRW0iy+Bvsxn ElGa/IQgUs85zRO9xdKzcYyT34uqX9+VWAfs2GLcXdEBm4Z87eszLjqoWtDzzFw0dpPm PmpSZnZMWDQGbyVuXKEbwN/dtPQOgU2iVf8sk9wdF4BRz4fqJu3sIAl3Bf9fhcoC2prI GOnA== 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=xtBzfTtDG7oKM+x9UqD0E0Ye5bVhGGdjMoStNboz9r0=; b=gQZ12cqXYNjgiQvsiAmos7ZH4ws6v1pYGpyVqWfIQC3tukVvNhEBgORSgVCIbAYVxq QeyZt6vp8G6gJnpivycCwrUHDFt4XmmH/7T3UY7uOEONt+lT0LHrm41Hdknd21ewJIrS 49O4I64MXrmyp0+kAgzBciGxeIup/XgO9qhpwR5js385SHWRFEFWwmgpxVBOyUwHeu1O uZybBXW+FCBjBErHhDy0NyBQ/mAnna08DFUhEzPiqw2/R/FkvSaDDxvYbR+LwCG4WvSX ZNFIdYea6SU6KhuBA8DJDqaPGg2n9inNEGE6+FEoMUCgu+03U5yZrCww8cAtPBHSoAtp R5ew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b=3khVdGAz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u18si11142314plg.8.2022.01.22.16.16.12; Sat, 22 Jan 2022 16:16:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@brainfault-org.20210112.gappssmtp.com header.s=20210112 header.b=3khVdGAz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232479AbiAVEKn (ORCPT + 99 others); Fri, 21 Jan 2022 23:10:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229455AbiAVEKm (ORCPT ); Fri, 21 Jan 2022 23:10:42 -0500 Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8674C06173B for ; Fri, 21 Jan 2022 20:10:36 -0800 (PST) Received: by mail-wm1-x336.google.com with SMTP id c66so19346139wma.5 for ; Fri, 21 Jan 2022 20:10:36 -0800 (PST) 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=xtBzfTtDG7oKM+x9UqD0E0Ye5bVhGGdjMoStNboz9r0=; b=3khVdGAzaP4cQaVtq0HqR9t2SgSWu0COjVPL79LLhIjzhULd13thKBLqgrjopbvSr3 wlasjQ0Om1cjyWDMZ1b/u5EzP+bnoY8fp3WwM4IM5ovzXGd1ON/+JXeVcrv7DEeEEXjV fgwKJVGLREOR8VjIbMMr7a3iEmgBfsz4LpoAjOD7iem6oLcwrP2nS8m349y5HvnN+sfQ KwPaC9w0G3jRr5EcaYWDFgh6e8AltN4veUgmbzxRn1gHnI9V4o3Oo5+Buh1HCunNbe4X bR8b4uWXLVGoOo7gvIB6Hmgc6UL6nCHGR9/NmY7fE9owoFb6hlYTr9lBKWEdbRIDY8Gw njwQ== 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=xtBzfTtDG7oKM+x9UqD0E0Ye5bVhGGdjMoStNboz9r0=; b=j58sIxUwmMVTRqKTMG6eVaQ9Fr/otuaXCU7qbQj2b3sHK4MPXgkuGT+f1bZ2CWI1mc 2wScPDYLZnh6LdKJ6bQ5Dw+XWfjc+yPrS2TFSA+mx9t5MCaOb374Cj2PMN1tJjFI/mFu fhDb9oB6MK1Wg5uHIoHsza4xx8vkjjobLhIDX7UOBgGTmiJKjasDeQIflgKrm2yhvb1f Tkj/9oswiGGNRymQK54o1P+XLPO/mXX1xjzyAeUax7oyhz3haDhCcOdZP+x6TeGgyu9V hOFf2qJ9pVuNdHI65+Slpf5Yl7r9rJJ2I+5mZp5a5loE0dPjuadpgbNxJiUiUb4b0JJD 9pXQ== X-Gm-Message-State: AOAM531aWblDOv5HYWKLnUsnLbOw5qvCCSFRYASeo46Ys44h7lMrPhkZ jLPP3Mc81O5FX4L7tFElAeI56HfEFNCODHUzNlKj5w== X-Received: by 2002:a7b:c181:: with SMTP id y1mr3058395wmi.137.1642824635202; Fri, 21 Jan 2022 20:10:35 -0800 (PST) MIME-Version: 1.0 References: <20220121163618.351934-1-heiko@sntech.de> <20220121163618.351934-2-heiko@sntech.de> In-Reply-To: <20220121163618.351934-2-heiko@sntech.de> From: Anup Patel Date: Sat, 22 Jan 2022 09:40:23 +0530 Message-ID: Subject: Re: [PATCH v5 01/14] riscv: only use IPIs to handle cache-flushes on remote cpus To: Heiko Stuebner Cc: Palmer Dabbelt , Paul Walmsley , Albert Ou , linux-riscv , DTML , "linux-kernel@vger.kernel.org List" , Rob Herring , Wei Fu , liush , Guo Ren , Atish Patra , Drew Fustini , Christoph Hellwig , Arnd Bergmann , Chen-Yu Tsai , Maxime Ripard , Daniel Lustig , Greg Favor , Andrea Mondelli , Jonathan Behrens , Xinhaoqu , Bill Huffman , Nick Kossifidis , Allen Baum , Josh Scheid , Richard Trauben , Samuel Holland , Christoph Muellner , Philipp Tomsich Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 21, 2022 at 10:07 PM Heiko Stuebner wrote: > > Right now, the flush_icache functions always use the SBI remote-fence > when SBI is available, leaving using IPIs as a fallback mechanism. > > IPIs on the other hand are more flexible, as the ipi_ops are initially > set to go through SBI but later will be overwritten to go through the > ACLINT/CLINT. > > In a discussion we had, Nick was of the opinion that "In general we > should prefer doing IPIs on S-mode through CLINT instead of going > through SBI/M-mode, so IMHO we should only be using > on_each_cpu_mask(ipi_remote_fence_i) on flush_icache_all()/ > flush_icache_mm() and remove any explicit calls to sbi_remote_fence_i(), > because this way we continue using SBI for doing remote fences even after > CLINT/ACLINT driver is registered, instead of using direct IPIs through > CLINT/ACLINT." > > So follow this suggestion and just do ipi calls to have the proper kernel > parts do them, > > This also fixes the null-ptr dereference happening when flush_icache_all() > is called before sbi_init(). > > Suggested-by: Nick Kossifidis > Signed-off-by: Heiko Stuebner For Guest/VM, only virtual IMSIC provides faster IPIs so in absence of virtual IMSIC, the SBI IPI based IPIs are the best approach. Like Atish mentioned, please base this work on the ACLINT series because the ACLINT series adds required IPI infrastructure which helps us select SBI IPI versus direct S-mode IPI based on hardware capability. Regards, Anup > --- > arch/riscv/mm/cacheflush.c | 8 +------- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/arch/riscv/mm/cacheflush.c b/arch/riscv/mm/cacheflush.c > index 6cb7d96ad9c7..c35375cd52ec 100644 > --- a/arch/riscv/mm/cacheflush.c > +++ b/arch/riscv/mm/cacheflush.c > @@ -17,11 +17,7 @@ static void ipi_remote_fence_i(void *info) > void flush_icache_all(void) > { > local_flush_icache_all(); > - > - if (IS_ENABLED(CONFIG_RISCV_SBI)) > - sbi_remote_fence_i(NULL); > - else > - on_each_cpu(ipi_remote_fence_i, NULL, 1); > + on_each_cpu(ipi_remote_fence_i, NULL, 1); > } > EXPORT_SYMBOL(flush_icache_all); > > @@ -66,8 +62,6 @@ void flush_icache_mm(struct mm_struct *mm, bool local) > * with flush_icache_deferred(). > */ > smp_mb(); > - } else if (IS_ENABLED(CONFIG_RISCV_SBI)) { > - sbi_remote_fence_i(&others); > } else { > on_each_cpu_mask(&others, ipi_remote_fence_i, NULL, 1); > } > -- > 2.30.2 >