Message ID | 20231026233837.612405-1-debug@rivosinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp240689vqb; Thu, 26 Oct 2023 16:41:10 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEw9BD0x3LeKL55/eW69mriHSr55ZaGi87x6HEJSTHfOuhQH2KqqUCcGhq9VlOvCysZtbOa X-Received: by 2002:a05:6808:d4d:b0:3a8:6b4d:6b78 with SMTP id w13-20020a0568080d4d00b003a86b4d6b78mr1086866oik.35.1698363670573; Thu, 26 Oct 2023 16:41:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698363670; cv=none; d=google.com; s=arc-20160816; b=f+fZvJiPEYmAimFaxLw/+6Pi3dsLc9++WnP4KE1cGQbgE7ek4FrPgbkWmS4ld3SxmC H8UZAFGiaPxuM4DrRUWZ79kSQ0hgUjUvWRx+aiDuAjy0FabtxpcfdeJ+0deLC8QkBUMF 7/owM2YU/xSyi2Nk7f2m76WCAcp6sR88fE8KT6S9HiE6d8fcDkZa6X2zQiqJxeRXQAPP iavrwHzjiU1ZxBL8r5hzq/CcSGmw+gDTHSdvbaBKyP5zAXVM4YayByJB+3RntHQKgx8n 4l+sSlbySQrTu2CHUbn05vKun9VMhNaXUR7niaIQfGjBVkuTccvNvDfpljQbT5cPWZ3u mJlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:content-transfer-encoding:mime-version :message-id:date:subject:cc:from:dkim-signature; bh=8q790Td8gv55CpXw6jh1r5+WUtiBYMYeRT8D2CcfTbo=; fh=War6McorR/mNIlUDsN1yTF1JkxGInUlGKjCbHCpKYKM=; b=E93vy/HPoehSpFpjh6ylo3DrTYrf6NgHBiS9jUUj6G3Q4wno3QopTIVnmCJPuMuNxi 0XQDwgseHZvBFo/4nOL6znGrj+ctvoOQjARYAWxtBVKYCilGmuhl/pClnLVdTRXoX5Rv W3O2b85qzg18HbXQgUTB3BG/A8brvgwPLxLGYoycDeHerFnOUci1EwCOWw8ON86rrdL8 ayC/DRNts/v+qo/+ZVxn5FybdmuwjJXFAJaHyUQtDqP+fhnVgbOp8s29ejLaguYQ3MKk zczRzGkfc6z7iT9TjnW1TfSeiJZNBHWeI/q2pP3Ded538vX2SJSqB37RzmBuHq5nOAQq 2HyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=0t70StkM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id g9-20020a25ae49000000b00d9a5ed8b678si763055ybe.76.2023.10.26.16.41.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Oct 2023 16:41:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=fail header.i=@rivosinc-com.20230601.gappssmtp.com header.s=20230601 header.b=0t70StkM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 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 groat.vger.email (Postfix) with ESMTP id C38578260F49; Thu, 26 Oct 2023 16:41:07 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229694AbjJZXjW (ORCPT <rfc822;aposhian.dev@gmail.com> + 26 others); Thu, 26 Oct 2023 19:39:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59216 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229437AbjJZXjU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 26 Oct 2023 19:39:20 -0400 Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE8C6187 for <linux-kernel@vger.kernel.org>; Thu, 26 Oct 2023 16:39:16 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id 5614622812f47-3b3e13fc1f7so916453b6e.0 for <linux-kernel@vger.kernel.org>; Thu, 26 Oct 2023 16:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1698363556; x=1698968356; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=8q790Td8gv55CpXw6jh1r5+WUtiBYMYeRT8D2CcfTbo=; b=0t70StkM57mDEH5BL/0SDyonh+2YTbDDvRHnjTC0z+l4Uqdv9H5KfuX9XUHQh/igf+ h69L3TORi+AjhkLA8Mk+aoCU72jGla6Dsh55rdQjgWGXOYEt2gT8A9KsgprYB39HLvwc IzG9xPjnn5ugv3VEYu5q7xwDKKhpGSLzWzeq6IicMBFRQtHMFeFm52Dod70/MxWuZjUx UDTQeM1ThuA8pOdTDWWuWeIeAIUIL604DOZEd0eISsgwlCbHQTVHpiLCQkHVheWGhh4M qBq2JvwB4ybo8x/qAvj9/E7AhZqFc1uSBdPqPDW1+DlSQRhcRPCG06pCYrvliW6wr/xg hZyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698363556; x=1698968356; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8q790Td8gv55CpXw6jh1r5+WUtiBYMYeRT8D2CcfTbo=; b=QJ6rm6CnOkEFmj1Pws+3YpTqovO7E690Fr3GKzmY9ejYsiA1Dqb9hnP0bILvjwAXTn C1Ft6yJWL99U9/TblrJ980qxwZOS5Yf9OF66WBkPGqlCVpQMnH38rnhKrKI72x13/3Yo x2NTh3AH8s7+PN+BOxu5+NnNVldxGtsfC3EM3+bft523bNe2L9yl6G1SWplXGU7ROZ1I mRmLnLKU8AOI+8OhxHRCDby93QZIoQSHN12Twe6c/xtbmEYCFaksxi06fxa3HJStJ9De X1CVeF7yd+5sdcK49J/elH19eqUvaQrlvyqCLAc75aMoeeuOU6UK95I/f6R6gYLVYrhw WL0A== X-Gm-Message-State: AOJu0Yzql92A7YTM29ox/w8zyuc5gaAx+ISUvH60OC66EJUglWZOHxnv psxr8lRC3usASF4jybk5scOHeg== X-Received: by 2002:a05:6808:1594:b0:3a7:5557:16ba with SMTP id t20-20020a056808159400b003a7555716bamr935245oiw.27.1698363555922; Thu, 26 Oct 2023 16:39:15 -0700 (PDT) Received: from debug.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id n9-20020a05680803a900b003ae51628725sm76809oie.13.2023.10.26.16.39.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Oct 2023 16:39:15 -0700 (PDT) From: Deepak Gupta <debug@rivosinc.com> Cc: woodrow.shen@sifive.com, Deepak Gupta <debug@rivosinc.com>, Andrew Jones <ajones@ventanamicro.com>, Palmer Dabbelt <palmer@rivosinc.com>, Jan Kiszka <jan.kiszka@siemens.com>, Kieran Bingham <kbingham@kernel.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Andrew Morton <akpm@linux-foundation.org>, Glenn Washburn <development@efficientek.com>, Jeff Xie <xiehuan09@gmail.com>, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: [PATCH v6] scripts/gdb: add lx_current support for riscv Date: Thu, 26 Oct 2023 16:38:23 -0700 Message-ID: <20231026233837.612405-1-debug@rivosinc.com> X-Mailer: git-send-email 2.42.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email To: unlisted-recipients:; (no To-header on input) 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 (groat.vger.email [0.0.0.0]); Thu, 26 Oct 2023 16:41:07 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1780863384189867300 X-GMAIL-MSGID: 1780863384189867300 |
Series |
[v6] scripts/gdb: add lx_current support for riscv
|
|
Commit Message
Deepak Gupta
Oct. 26, 2023, 11:38 p.m. UTC
csr_sscratch CSR holds current task_struct address when hart is in user space. Trap handler on entry spills csr_sscratch into "tp" (x2) register and zeroes out csr_sscratch CSR. Trap handler on exit reloads "tp" with expected user mode value and place current task_struct address again in csr_sscratch CSR. This patch assumes "tp" is pointing to task_struct. If value in csr_sscratch is numerically greater than "tp" then it assumes csr_sscratch is correct address of current task_struct. This logic holds when - hart is in user space, "tp" will be less than csr_sscratch. - hart is in kernel space but not in trap handler, "tp" will be more than csr_sscratch (csr_sscratch being equal to 0). - hart is executing trap handler - "tp" is still pointing to user mode but csr_sscratch contains ptr to task_struct. Thus numerically higher. - "tp" is pointing to task_struct but csr_sscratch now contains either 0 or numerically smaller value (transiently holds user mode tp) Signed-off-by: Deepak Gupta <debug@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Tested-by: Hsieh-Tseng Shen <woodrow.shen@sifive.com> --- Since patch has changed a little bit from v1 and I didn't include changelog earlier, here it is. v1 --> v2: - added logic to locate task_struct irrespective of priv - made locating task_struct agnostic to bitness(32 vs 64). - added caching of ulong type in scripts/gdb/linux/utils.py - added more descriptive commit message v2 --> v3: - amended commit message and source line to fit column width v3 --> v4: - amended commit message and remove whitespace in source - added Reviewed-by for reviewers v4 --> v5: - changing the order of changelog and sign off/review tags in commit v5 --> v6: - rebased on 6.6-rc5. dropped changes in utils.py as they're upstream --- scripts/gdb/linux/cpus.py | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
Comments
Ping + CC: akpm@linux-foundation.org Who should I ping to make sure that it lands up in mainline? It's quite a trivial change to support lx_current riscv arch. -Deepak On Thu, Oct 26, 2023 at 04:38:23PM -0700, Deepak Gupta wrote: >csr_sscratch CSR holds current task_struct address when hart is in >user space. Trap handler on entry spills csr_sscratch into "tp" (x2) >register and zeroes out csr_sscratch CSR. Trap handler on exit reloads >"tp" with expected user mode value and place current task_struct address >again in csr_sscratch CSR. > >This patch assumes "tp" is pointing to task_struct. If value in >csr_sscratch is numerically greater than "tp" then it assumes csr_sscratch >is correct address of current task_struct. This logic holds when > - hart is in user space, "tp" will be less than csr_sscratch. > - hart is in kernel space but not in trap handler, "tp" will be more > than csr_sscratch (csr_sscratch being equal to 0). > - hart is executing trap handler > - "tp" is still pointing to user mode but csr_sscratch contains > ptr to task_struct. Thus numerically higher. > - "tp" is pointing to task_struct but csr_sscratch now contains > either 0 or numerically smaller value (transiently holds > user mode tp) > >Signed-off-by: Deepak Gupta <debug@rivosinc.com> >Reviewed-by: Andrew Jones <ajones@ventanamicro.com> >Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> >Acked-by: Palmer Dabbelt <palmer@rivosinc.com> >Tested-by: Hsieh-Tseng Shen <woodrow.shen@sifive.com> > >--- >Since patch has changed a little bit from v1 and I didn't include >changelog earlier, here it is. > >v1 --> v2: > - added logic to locate task_struct irrespective of priv > - made locating task_struct agnostic to bitness(32 vs 64). > - added caching of ulong type in scripts/gdb/linux/utils.py > - added more descriptive commit message > >v2 --> v3: > - amended commit message and source line to fit column width > >v3 --> v4: > - amended commit message and remove whitespace in source > - added Reviewed-by for reviewers > >v4 --> v5: > - changing the order of changelog and sign off/review tags in commit > >v5 --> v6: > - rebased on 6.6-rc5. dropped changes in utils.py as they're upstream >--- > scripts/gdb/linux/cpus.py | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > >diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py >index 255dc18cb9da..cba589e5b57d 100644 >--- a/scripts/gdb/linux/cpus.py >+++ b/scripts/gdb/linux/cpus.py >@@ -179,6 +179,21 @@ def get_current_task(cpu): > else: > raise gdb.GdbError("Sorry, obtaining the current task is not allowed " > "while running in userspace(EL0)") >+ elif utils.is_target_arch("riscv"): >+ current_tp = gdb.parse_and_eval("$tp") >+ scratch_reg = gdb.parse_and_eval("$sscratch") >+ >+ # by default tp points to current task >+ current_task = current_tp.cast(task_ptr_type) >+ >+ # scratch register is set 0 in trap handler after entering kernel. >+ # When hart is in user mode, scratch register is pointing to task_struct. >+ # and tp is used by user mode. So when scratch register holds larger value >+ # (negative address as ulong is larger value) than tp, then use scratch register. >+ if (scratch_reg.cast(utils.get_ulong_type()) > current_tp.cast(utils.get_ulong_type())): >+ current_task = scratch_reg.cast(task_ptr_type) >+ >+ return current_task.dereference() > else: > raise gdb.GdbError("Sorry, obtaining the current task is not yet " > "supported with this arch") >-- >2.42.0 >
On Thu, 2 Nov 2023 08:45:17 -0700 Deepak Gupta <debug@rivosinc.com> wrote: > Ping > > + CC: akpm@linux-foundation.org > > Who should I ping to make sure that it lands up in mainline? > It's quite a trivial change to support lx_current riscv arch. I moved it from mm.git's mm-nonmm-unstable branch into the mm-nonmm-stable branch earlier this week. mm-nonmm-stable is what I'll be sending to Linus later this merge window.
On Thu, Nov 2, 2023 at 8:56 AM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Thu, 2 Nov 2023 08:45:17 -0700 Deepak Gupta <debug@rivosinc.com> wrote: > > > Ping > > > > + CC: akpm@linux-foundation.org > > > > Who should I ping to make sure that it lands up in mainline? > > It's quite a trivial change to support lx_current riscv arch. > > I moved it from mm.git's mm-nonmm-unstable branch into the > mm-nonmm-stable branch earlier this week. mm-nonmm-stable is what I'll > be sending to Linus later this merge window. > Thanks
diff --git a/scripts/gdb/linux/cpus.py b/scripts/gdb/linux/cpus.py index 255dc18cb9da..cba589e5b57d 100644 --- a/scripts/gdb/linux/cpus.py +++ b/scripts/gdb/linux/cpus.py @@ -179,6 +179,21 @@ def get_current_task(cpu): else: raise gdb.GdbError("Sorry, obtaining the current task is not allowed " "while running in userspace(EL0)") + elif utils.is_target_arch("riscv"): + current_tp = gdb.parse_and_eval("$tp") + scratch_reg = gdb.parse_and_eval("$sscratch") + + # by default tp points to current task + current_task = current_tp.cast(task_ptr_type) + + # scratch register is set 0 in trap handler after entering kernel. + # When hart is in user mode, scratch register is pointing to task_struct. + # and tp is used by user mode. So when scratch register holds larger value + # (negative address as ulong is larger value) than tp, then use scratch register. + if (scratch_reg.cast(utils.get_ulong_type()) > current_tp.cast(utils.get_ulong_type())): + current_task = scratch_reg.cast(task_ptr_type) + + return current_task.dereference() else: raise gdb.GdbError("Sorry, obtaining the current task is not yet " "supported with this arch")