Message ID | 20231213-fencei-v3-2-b75158238eb7@rivosinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:3b04:b0:fb:cd0c:d3e with SMTP id c4csp8141666dys; Wed, 13 Dec 2023 14:48:24 -0800 (PST) X-Google-Smtp-Source: AGHT+IFjtN8CpEN0Tbi5s8KIXXTuGI+viBvd5xfJEvFeIAuvzDOVuJBuD34cxDqdJmcYM/ht+yN4 X-Received: by 2002:a17:902:e843:b0:1d0:9979:7bd3 with SMTP id t3-20020a170902e84300b001d099797bd3mr5929623plg.16.1702507704486; Wed, 13 Dec 2023 14:48:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702507704; cv=none; d=google.com; s=arc-20160816; b=ONje6ByIWbnJjtiU0zq0d8k1sifMZkg7aa8kmg5+o5qoP9T6lvKtrQYSHafoYqQ2CH v3wDNIQhEJl9ZJl6lYgiMs2RantFVnaS5wIey+DQZNgeBhcEKGUFQn6ichwF68kjniLY z1fR3DiyEtPPjOp8hpM9TVAUIPlX2cDrYAfXgkMHeErpFyVJmXz4eRVb0xk+ku9oTFdF mtVaKOmnxC8Mo6GfRcqu8365rkFdZSr4XgfDS/S1MLz6Q/fP0mDO9tZTFwoh5Yb64a7U 8nbdvO/78Ibfcn/JRrTufKNnLOsHZs0OMub5jm7zYKpdLUr4ce6nVOOToUr3rDWHtKsi vr9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=3S3MR9WYTuBImuNJhXJPIP3GzfMK1QacwIWQCdBwVhY=; fh=wzPja/om1CPWeXWPvnQuMAUDNXEwF81Icptgurz37pw=; b=H24O+xeMC17TjeQHo82KexXnpzgy5DJ46GDKpVpSkoCiM/LOnvEDqAZ8X48lojm4FL a9II9XmnXDi2BMMSzDNGDo7Qsd/cdjPdYTIVJNScz5KM1Bl72DcOf/owwNQuMkKJTdfY uaIGyOzXTRbDNoYRYzcZqzZt3LgPv1J5jBrORzvYVutMOWlFE99jeSVvOL5R4bh4axci TiXmpuehUO+CHNaK6PvEU5GqLozI0WFbF5dFHXPmv1OjUYfk1zaHM6Afc64NL9UZss6P I+EiU/fZcsnYOrnsH0UsqzkZvBpMtySUuWfSPabtQ6DEkRsDoR+mWb0hvDM2cG9ncZlR E1tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=srqHirtx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id i7-20020a17090332c700b001d34932e41bsi2243151plr.167.2023.12.13.14.48.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 14:48:24 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=srqHirtx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id EBFDD802F6AA; Wed, 13 Dec 2023 14:48:21 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235411AbjLMWr4 (ORCPT <rfc822;dexuan.linux@gmail.com> + 99 others); Wed, 13 Dec 2023 17:47:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39612 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1442831AbjLMWru (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 13 Dec 2023 17:47:50 -0500 Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A62B6E4 for <linux-kernel@vger.kernel.org>; Wed, 13 Dec 2023 14:47:55 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id 46e09a7af769-6d9e756cf32so4964685a34.2 for <linux-kernel@vger.kernel.org>; Wed, 13 Dec 2023 14:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1702507675; x=1703112475; darn=vger.kernel.org; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to; bh=3S3MR9WYTuBImuNJhXJPIP3GzfMK1QacwIWQCdBwVhY=; b=srqHirtxC7GROnNMHJ6RKmFGNx7R+EtXMAzhPcEdtg6jwmV/C+XEpg88rKMd2fDdk5 YVNmsxOHKFsZwytuTsCioAIUSb5g2i/kEkiHJ+UV2K4qAiCpI35l7PatMno0Vor+hH6b OkKGMAxdzzFf9Mkn7HgajA0UnHa+NlY1NIIBnE9gMEyVFibg92n90bJWOGMMiSxAH0t4 GAVhOBdOqeYuVkRJ8PCZrX9xLAS4N304R0ojqiEjaHKSCLpf0hxJj9G70Iv46peX8zrL i4sFIDILWl7ExFi30u7ym2PkasArPGoKd8lzGnfVCo/Q3Oo5KttzwQU3HMy/QMIJipKg PNTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702507675; x=1703112475; h=cc:to:in-reply-to:references:message-id:content-transfer-encoding :mime-version:subject:date:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=3S3MR9WYTuBImuNJhXJPIP3GzfMK1QacwIWQCdBwVhY=; b=h5Flcffk3W8M2VSYBF2ECi5MdVQgEkQ26xoqZMYQRAaFLFq+bya6E9E13XA4lz9QqY 3F2hQHVKCzMydcYyj6CRsAHrCzEgP/51eIHEZOHj0tqRXF/4XbcyHOZ6pAOh4zWQW/Ca 4ZW0x2IENxHrGmBrsGTeCC1fnLN0TtZJY5iYFb/wXrvDRsWfB/NUNaE0uNsjfbTL/9Ps BRIdMVX81byAlFc94N1kCBt5bOTwQAD7UakWPC1lHLRCvOZidpmtOQoOh6u1MLqfXmIX WpdJun0+2yMVtEF1rjCuKlov+cNmxhP0475IWCgvnqoOqD8Riuq4NM3U2MXy7N9xmRgj 9Q5g== X-Gm-Message-State: AOJu0Yx3RWS5IZqnouvyZ0MPGE9R4IkF03ArBg0t9oMXngGFGJHMOJYX ZzSIEVASzKJ+1Ai7voYBNE5PWQ== X-Received: by 2002:a05:6830:10cb:b0:6d9:e37f:5c54 with SMTP id z11-20020a05683010cb00b006d9e37f5c54mr8981554oto.9.1702507674986; Wed, 13 Dec 2023 14:47:54 -0800 (PST) Received: from charlie.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id bk21-20020a056830369500b006d855e2c56csm2375157otb.31.2023.12.13.14.47.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Dec 2023 14:47:54 -0800 (PST) From: Charlie Jenkins <charlie@rivosinc.com> Date: Wed, 13 Dec 2023 14:47:48 -0800 Subject: [PATCH v3 2/2] documentation: Document PR_RISCV_SET_ICACHE_FLUSH_CTX prctl MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20231213-fencei-v3-2-b75158238eb7@rivosinc.com> References: <20231213-fencei-v3-0-b75158238eb7@rivosinc.com> In-Reply-To: <20231213-fencei-v3-0-b75158238eb7@rivosinc.com> To: Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Jonathan Corbet <corbet@lwn.net>, Conor Dooley <conor.dooley@microchip.com>, =?utf-8?b?Q2zDqW1lbnQgTMOpZ2Vy?= <cleger@rivosinc.com> Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Charlie Jenkins <charlie@rivosinc.com> X-Mailer: b4 0.12.3 X-Developer-Signature: v=1; a=ed25519-sha256; t=1702507670; l=4185; i=charlie@rivosinc.com; s=20231120; h=from:subject:message-id; bh=zPaRO2ks3l/75pkgWBpZ4nSSEIYV6K0VRBbOkUO2jEY=; b=FhysUS+fsKXjyq0qV4ESXY/r9f9YHqD57UdPggn5+823NiPGLggILNdzlx/BcMFogfJIEdvRy M8mdMMi6/hrBe52bmDrZrvSpfL+Om8qXAVgapW/bkUDvXMgqvt+LFBA X-Developer-Key: i=charlie@rivosinc.com; a=ed25519; pk=t4RSWpMV1q5lf/NWIeR9z58bcje60/dbtxxmoSfBEcs= X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Wed, 13 Dec 2023 14:48:22 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785208718742516627 X-GMAIL-MSGID: 1785208718742516627 |
Series |
riscv: Create and document PR_RISCV_SET_ICACHE_FLUSH_CTX prctl
|
|
Commit Message
Charlie Jenkins
Dec. 13, 2023, 10:47 p.m. UTC
Provide documentation that explains how to properly do CMODX in riscv.
Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
---
Documentation/arch/riscv/cmodx.rst | 98 ++++++++++++++++++++++++++++++++++++++
Documentation/arch/riscv/index.rst | 1 +
2 files changed, 99 insertions(+)
Comments
On Wed, Dec 13, 2023 at 2:48 PM Charlie Jenkins <charlie@rivosinc.com> wrote: > > Provide documentation that explains how to properly do CMODX in riscv. > > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> > --- > Documentation/arch/riscv/cmodx.rst | 98 ++++++++++++++++++++++++++++++++++++++ > Documentation/arch/riscv/index.rst | 1 + > 2 files changed, 99 insertions(+) > > diff --git a/Documentation/arch/riscv/cmodx.rst b/Documentation/arch/riscv/cmodx.rst > new file mode 100644 > index 000000000000..20f327d85116 > --- /dev/null > +++ b/Documentation/arch/riscv/cmodx.rst > @@ -0,0 +1,98 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +============================================================================== > +Concurrent Modification and Execution of Instructions (CMODX) for RISC-V Linux > +============================================================================== > + > +CMODX is a programming technique where a program executes instructions that were > +modified by the program itself. Instruction storage and the instruction cache > +(icache) is not guaranteed to be synchronized on RISC-V hardware. Therefore, the > +program must enforce its own synchonization with the unprivileged fence.i/ /s/synchonization/synchronization > +instruction. > + > +However, the default Linux ABI prohibits the use of fence.i in userspace > +applications. At any point the scheduler may migrate a task onto a new hart. If > +migration occurs after the userspace synchronized the icache and instruction > +storage with fence.i, the icache will no longer be clean. This is due to the > +behavior of fence.i only affecting the hart that it is called on. Thus, the hart > +that the task has been migrated to, may not have synchronized instruction > +storage and icache. > + > +There are two ways to solve this problem: use the riscv_flush_icache() syscall, > +or use the ``PR_RISCV_SET_ICACHE_FLUSH_CTX`` prctl(). The syscall should be used > +when the application very rarely needs to flush the icache. If the icache will The syscall is a one time operation while prctl is sticky. It would be great if we can add a little more context why the syscall behaves this way compared to prctl. > +need to be flushed many times in the lifetime of the application, the prctl > +should be used. > + > +The prctl informs the kernel that it must emit synchronizing instructions upon > +task migration. The program itself must emit synchonizing instructions when /s/synchonizing/synchronizing > +necessary as well. > + > +1. prctl() Interface > +--------------------- > + > +Before the program emits their first icache flushing instruction, the program > +must call this prctl(). > + > +* prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, unsigned long ctx, unsigned long per_thread) > + > + Sets the icache flushing context. If per_thread is 0, context will be > + applied per process, otherwise if per_thread is 1 context will be > + per-thread. Any other number will have undefined behavior. > + > + * :c:macro:`PR_RISCV_CTX_SW_FENCEI`: Allow fence.i to be called in > + userspace. > + > +Example usage: > + > +The following files are meant to be compiled and linked with each other. The > +modify_instruction() function replaces an add with 0 with an add with one, > +causing the instruction sequence in get_value() to change from returning a zero > +to returning a one. > + > +cmodx.c:: > + > + #include <stdio.h> > + #include <sys/prctl.h> > + > + extern int get_value(); > + extern void modify_instruction(); > + > + int main() > + { > + int value = get_value(); > + printf("Value before cmodx: %d\n", value); > + > + // Call prctl before first fence.i is called inside modify_instruction > + prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, PR_RISCV_CTX_SW_FENCEI, 0); > + modify_instruction(); > + > + value = get_value(); > + printf("Value after cmodx: %d\n", value); > + return 0; > + } > + > +cmodx.S:: > + > + .option norvc > + > + .text > + .global modify_instruction > + modify_instruction: > + lw a0, new_insn > + lui a5,%hi(old_insn) > + sw a0,%lo(old_insn)(a5) > + fence.i > + ret > + > + .section modifiable, "awx" > + .global get_value > + get_value: > + li a0, 0 > + old_insn: > + addi a0, a0, 0 > + ret > + > + .data > + new_insn: > + addi a0, a0, 1 > diff --git a/Documentation/arch/riscv/index.rst b/Documentation/arch/riscv/index.rst > index 4dab0cb4b900..eecf347ce849 100644 > --- a/Documentation/arch/riscv/index.rst > +++ b/Documentation/arch/riscv/index.rst > @@ -13,6 +13,7 @@ RISC-V architecture > patch-acceptance > uabi > vector > + cmodx > > features > > > -- > 2.43.0 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
On Fri, Jan 05, 2024 at 06:52:12PM -0800, Atish Patra wrote: > On Wed, Dec 13, 2023 at 2:48 PM Charlie Jenkins <charlie@rivosinc.com> wrote: > > > > Provide documentation that explains how to properly do CMODX in riscv. > > > > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> > > --- > > Documentation/arch/riscv/cmodx.rst | 98 ++++++++++++++++++++++++++++++++++++++ > > Documentation/arch/riscv/index.rst | 1 + > > 2 files changed, 99 insertions(+) > > > > diff --git a/Documentation/arch/riscv/cmodx.rst b/Documentation/arch/riscv/cmodx.rst > > new file mode 100644 > > index 000000000000..20f327d85116 > > --- /dev/null > > +++ b/Documentation/arch/riscv/cmodx.rst > > @@ -0,0 +1,98 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > +============================================================================== > > +Concurrent Modification and Execution of Instructions (CMODX) for RISC-V Linux > > +============================================================================== > > + > > +CMODX is a programming technique where a program executes instructions that were > > +modified by the program itself. Instruction storage and the instruction cache > > +(icache) is not guaranteed to be synchronized on RISC-V hardware. Therefore, the > > +program must enforce its own synchonization with the unprivileged fence.i/ > > /s/synchonization/synchronization > > > +instruction. > > + > > +However, the default Linux ABI prohibits the use of fence.i in userspace > > +applications. At any point the scheduler may migrate a task onto a new hart. If > > +migration occurs after the userspace synchronized the icache and instruction > > +storage with fence.i, the icache will no longer be clean. This is due to the > > +behavior of fence.i only affecting the hart that it is called on. Thus, the hart > > +that the task has been migrated to, may not have synchronized instruction > > +storage and icache. > > + > > +There are two ways to solve this problem: use the riscv_flush_icache() syscall, > > +or use the ``PR_RISCV_SET_ICACHE_FLUSH_CTX`` prctl(). The syscall should be used > > +when the application very rarely needs to flush the icache. If the icache will > > The syscall is a one time operation while prctl is sticky. > It would be great if we can add a little more context why the syscall > behaves this way compared to prctl. I can highlight the point that the prctl is sticky and the syscall is not. As for "why", they simply fill different roles. It is useful to have both a sticky and a non-sticky option. I chose the sticky operation to be a prctl rather than a generic syscall because the semantics of prctl is that they operate on process or thread scoped behavior which is what was needed. - Charlie > > > +need to be flushed many times in the lifetime of the application, the prctl > > +should be used. > > + > > +The prctl informs the kernel that it must emit synchronizing instructions upon > > +task migration. The program itself must emit synchonizing instructions when > > /s/synchonizing/synchronizing > > > +necessary as well. > > + > > +1. prctl() Interface > > +--------------------- > > + > > +Before the program emits their first icache flushing instruction, the program > > +must call this prctl(). > > + > > +* prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, unsigned long ctx, unsigned long per_thread) > > + > > + Sets the icache flushing context. If per_thread is 0, context will be > > + applied per process, otherwise if per_thread is 1 context will be > > + per-thread. Any other number will have undefined behavior. > > + > > + * :c:macro:`PR_RISCV_CTX_SW_FENCEI`: Allow fence.i to be called in > > + userspace. > > + > > +Example usage: > > + > > +The following files are meant to be compiled and linked with each other. The > > +modify_instruction() function replaces an add with 0 with an add with one, > > +causing the instruction sequence in get_value() to change from returning a zero > > +to returning a one. > > + > > +cmodx.c:: > > + > > + #include <stdio.h> > > + #include <sys/prctl.h> > > + > > + extern int get_value(); > > + extern void modify_instruction(); > > + > > + int main() > > + { > > + int value = get_value(); > > + printf("Value before cmodx: %d\n", value); > > + > > + // Call prctl before first fence.i is called inside modify_instruction > > + prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, PR_RISCV_CTX_SW_FENCEI, 0); > > + modify_instruction(); > > + > > + value = get_value(); > > + printf("Value after cmodx: %d\n", value); > > + return 0; > > + } > > + > > +cmodx.S:: > > + > > + .option norvc > > + > > + .text > > + .global modify_instruction > > + modify_instruction: > > + lw a0, new_insn > > + lui a5,%hi(old_insn) > > + sw a0,%lo(old_insn)(a5) > > + fence.i > > + ret > > + > > + .section modifiable, "awx" > > + .global get_value > > + get_value: > > + li a0, 0 > > + old_insn: > > + addi a0, a0, 0 > > + ret > > + > > + .data > > + new_insn: > > + addi a0, a0, 1 > > diff --git a/Documentation/arch/riscv/index.rst b/Documentation/arch/riscv/index.rst > > index 4dab0cb4b900..eecf347ce849 100644 > > --- a/Documentation/arch/riscv/index.rst > > +++ b/Documentation/arch/riscv/index.rst > > @@ -13,6 +13,7 @@ RISC-V architecture > > patch-acceptance > > uabi > > vector > > + cmodx > > > > features > > > > > > -- > > 2.43.0 > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > -- > Regards, > Atish
On Fri, Jan 5, 2024 at 7:52 PM Charlie Jenkins <charlie@rivosinc.com> wrote: > > On Fri, Jan 05, 2024 at 06:52:12PM -0800, Atish Patra wrote: > > On Wed, Dec 13, 2023 at 2:48 PM Charlie Jenkins <charlie@rivosinc.com> wrote: > > > > > > Provide documentation that explains how to properly do CMODX in riscv. > > > > > > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> > > > --- > > > Documentation/arch/riscv/cmodx.rst | 98 ++++++++++++++++++++++++++++++++++++++ > > > Documentation/arch/riscv/index.rst | 1 + > > > 2 files changed, 99 insertions(+) > > > > > > diff --git a/Documentation/arch/riscv/cmodx.rst b/Documentation/arch/riscv/cmodx.rst > > > new file mode 100644 > > > index 000000000000..20f327d85116 > > > --- /dev/null > > > +++ b/Documentation/arch/riscv/cmodx.rst > > > @@ -0,0 +1,98 @@ > > > +.. SPDX-License-Identifier: GPL-2.0 > > > + > > > +============================================================================== > > > +Concurrent Modification and Execution of Instructions (CMODX) for RISC-V Linux > > > +============================================================================== > > > + > > > +CMODX is a programming technique where a program executes instructions that were > > > +modified by the program itself. Instruction storage and the instruction cache > > > +(icache) is not guaranteed to be synchronized on RISC-V hardware. Therefore, the > > > +program must enforce its own synchonization with the unprivileged fence.i/ > > > > /s/synchonization/synchronization > > > > > +instruction. > > > + > > > +However, the default Linux ABI prohibits the use of fence.i in userspace > > > +applications. At any point the scheduler may migrate a task onto a new hart. If > > > +migration occurs after the userspace synchronized the icache and instruction > > > +storage with fence.i, the icache will no longer be clean. This is due to the > > > +behavior of fence.i only affecting the hart that it is called on. Thus, the hart > > > +that the task has been migrated to, may not have synchronized instruction > > > +storage and icache. > > > + > > > +There are two ways to solve this problem: use the riscv_flush_icache() syscall, > > > +or use the ``PR_RISCV_SET_ICACHE_FLUSH_CTX`` prctl(). The syscall should be used > > > +when the application very rarely needs to flush the icache. If the icache will > > > > The syscall is a one time operation while prctl is sticky. > > It would be great if we can add a little more context why the syscall > > behaves this way compared to prctl. > > I can highlight the point that the prctl is sticky and the syscall is > not. > > As for "why", they simply fill different roles. It is useful to have > both a sticky and a non-sticky option. I chose the sticky operation to > be a prctl rather than a generic syscall because the semantics of prctl > is that they operate on process or thread scoped behavior which is what > was needed. > Yeah. That's what I was suggesting. It is enough for readers to understand the difference between the two approaches without reading the kernel source code. > - Charlie > > > > > > +need to be flushed many times in the lifetime of the application, the prctl > > > +should be used. > > > + > > > +The prctl informs the kernel that it must emit synchronizing instructions upon > > > +task migration. The program itself must emit synchonizing instructions when > > > > /s/synchonizing/synchronizing > > > > > +necessary as well. > > > + > > > +1. prctl() Interface > > > +--------------------- > > > + > > > +Before the program emits their first icache flushing instruction, the program > > > +must call this prctl(). > > > + > > > +* prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, unsigned long ctx, unsigned long per_thread) > > > + > > > + Sets the icache flushing context. If per_thread is 0, context will be > > > + applied per process, otherwise if per_thread is 1 context will be > > > + per-thread. Any other number will have undefined behavior. > > > + > > > + * :c:macro:`PR_RISCV_CTX_SW_FENCEI`: Allow fence.i to be called in > > > + userspace. > > > + > > > +Example usage: > > > + > > > +The following files are meant to be compiled and linked with each other. The > > > +modify_instruction() function replaces an add with 0 with an add with one, > > > +causing the instruction sequence in get_value() to change from returning a zero > > > +to returning a one. > > > + > > > +cmodx.c:: > > > + > > > + #include <stdio.h> > > > + #include <sys/prctl.h> > > > + > > > + extern int get_value(); > > > + extern void modify_instruction(); > > > + > > > + int main() > > > + { > > > + int value = get_value(); > > > + printf("Value before cmodx: %d\n", value); > > > + > > > + // Call prctl before first fence.i is called inside modify_instruction > > > + prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, PR_RISCV_CTX_SW_FENCEI, 0); > > > + modify_instruction(); > > > + > > > + value = get_value(); > > > + printf("Value after cmodx: %d\n", value); > > > + return 0; > > > + } > > > + > > > +cmodx.S:: > > > + > > > + .option norvc > > > + > > > + .text > > > + .global modify_instruction > > > + modify_instruction: > > > + lw a0, new_insn > > > + lui a5,%hi(old_insn) > > > + sw a0,%lo(old_insn)(a5) > > > + fence.i > > > + ret > > > + > > > + .section modifiable, "awx" > > > + .global get_value > > > + get_value: > > > + li a0, 0 > > > + old_insn: > > > + addi a0, a0, 0 > > > + ret > > > + > > > + .data > > > + new_insn: > > > + addi a0, a0, 1 > > > diff --git a/Documentation/arch/riscv/index.rst b/Documentation/arch/riscv/index.rst > > > index 4dab0cb4b900..eecf347ce849 100644 > > > --- a/Documentation/arch/riscv/index.rst > > > +++ b/Documentation/arch/riscv/index.rst > > > @@ -13,6 +13,7 @@ RISC-V architecture > > > patch-acceptance > > > uabi > > > vector > > > + cmodx > > > > > > features > > > > > > > > > -- > > > 2.43.0 > > > > > > > > > _______________________________________________ > > > linux-riscv mailing list > > > linux-riscv@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > -- > > Regards, > > Atish
diff --git a/Documentation/arch/riscv/cmodx.rst b/Documentation/arch/riscv/cmodx.rst new file mode 100644 index 000000000000..20f327d85116 --- /dev/null +++ b/Documentation/arch/riscv/cmodx.rst @@ -0,0 +1,98 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================================== +Concurrent Modification and Execution of Instructions (CMODX) for RISC-V Linux +============================================================================== + +CMODX is a programming technique where a program executes instructions that were +modified by the program itself. Instruction storage and the instruction cache +(icache) is not guaranteed to be synchronized on RISC-V hardware. Therefore, the +program must enforce its own synchonization with the unprivileged fence.i +instruction. + +However, the default Linux ABI prohibits the use of fence.i in userspace +applications. At any point the scheduler may migrate a task onto a new hart. If +migration occurs after the userspace synchronized the icache and instruction +storage with fence.i, the icache will no longer be clean. This is due to the +behavior of fence.i only affecting the hart that it is called on. Thus, the hart +that the task has been migrated to, may not have synchronized instruction +storage and icache. + +There are two ways to solve this problem: use the riscv_flush_icache() syscall, +or use the ``PR_RISCV_SET_ICACHE_FLUSH_CTX`` prctl(). The syscall should be used +when the application very rarely needs to flush the icache. If the icache will +need to be flushed many times in the lifetime of the application, the prctl +should be used. + +The prctl informs the kernel that it must emit synchronizing instructions upon +task migration. The program itself must emit synchonizing instructions when +necessary as well. + +1. prctl() Interface +--------------------- + +Before the program emits their first icache flushing instruction, the program +must call this prctl(). + +* prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, unsigned long ctx, unsigned long per_thread) + + Sets the icache flushing context. If per_thread is 0, context will be + applied per process, otherwise if per_thread is 1 context will be + per-thread. Any other number will have undefined behavior. + + * :c:macro:`PR_RISCV_CTX_SW_FENCEI`: Allow fence.i to be called in + userspace. + +Example usage: + +The following files are meant to be compiled and linked with each other. The +modify_instruction() function replaces an add with 0 with an add with one, +causing the instruction sequence in get_value() to change from returning a zero +to returning a one. + +cmodx.c:: + + #include <stdio.h> + #include <sys/prctl.h> + + extern int get_value(); + extern void modify_instruction(); + + int main() + { + int value = get_value(); + printf("Value before cmodx: %d\n", value); + + // Call prctl before first fence.i is called inside modify_instruction + prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, PR_RISCV_CTX_SW_FENCEI, 0); + modify_instruction(); + + value = get_value(); + printf("Value after cmodx: %d\n", value); + return 0; + } + +cmodx.S:: + + .option norvc + + .text + .global modify_instruction + modify_instruction: + lw a0, new_insn + lui a5,%hi(old_insn) + sw a0,%lo(old_insn)(a5) + fence.i + ret + + .section modifiable, "awx" + .global get_value + get_value: + li a0, 0 + old_insn: + addi a0, a0, 0 + ret + + .data + new_insn: + addi a0, a0, 1 diff --git a/Documentation/arch/riscv/index.rst b/Documentation/arch/riscv/index.rst index 4dab0cb4b900..eecf347ce849 100644 --- a/Documentation/arch/riscv/index.rst +++ b/Documentation/arch/riscv/index.rst @@ -13,6 +13,7 @@ RISC-V architecture patch-acceptance uabi vector + cmodx features