From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE,URIBL_DBL_BLOCKED_OPENDNS,URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=3.4.4 Received: from txout-a2-smtp.messagingengine.com (txout-a2-smtp.messagingengine.com [103.168.172.225]) by inbox.vuxu.org (Postfix) with ESMTP id 6CD9E2616D for ; Wed, 7 Jan 2026 01:03:42 +0100 (CET) Received: from localhost.localdomain (phl-topicbox-02.internal [10.202.2.220]) by mailtxout.phl.internal (Postfix) with ESMTP id 838A41C01AC for ; Tue, 6 Jan 2026 19:03:41 -0500 (EST) ARC-Authentication-Results: i=2; topicbox.com; arc=pass; dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=OiNiV0Ao header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; spf=pass smtp.mailfrom=rminnich@gmail.com smtp.helo=mail-lf1-f49.google.com; x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message has been altered)) (Message modified while forwarding at Topicbox) ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=mime-version:from:date:message-id:to :content-type:list-help:list-id:list-post:list-subscribe :reply-to:subject:content-transfer-encoding:list-unsubscribe; s= sysmsg-1; t=1767744221; bh=5yxZQm3mD+/bLKxlc4Vfm9DeadiTWLOQlxejO Gcsn+g=; b=MrkoFIMfpVhDIitoCBS/x4zWDYtCoSK5ZlDQqSbauwPwg4rZEgOvU JcAdVw5jA9NcqOy8fbZFXPcoYpXf/y1EyxjAD3ZOMqYqtXbUo//gWz0cONeMODKV uRXJ+Lksg7n0HPEImDf2mK1IT74I9vDJu8bvtUZ+cXh1Z/uDNgetDI= ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t= 1767744221; b=KmH4OYQ3th6o9wT2F6SO4ZIrP5EFY3eD7ud7eX+MBmB599VGc8 fFh/euuPtvehT//WmqW1XxEyhC919ZbZVPCV5vN+rF2m3/lhlL1zGmbNBzbA6L/m jNvN2q1SXB1tJllNRzkzcTeh/+hdFTKQ3GWvfVWjGe1fVB2UU2mZVL/OU= Authentication-Results: topicbox.com; arc=pass; dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=OiNiV0Ao header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; spf=pass smtp.mailfrom=rminnich@gmail.com smtp.helo=mail-lf1-f49.google.com; x-internal-arc=fail (as.1.topicbox.com=pass, ams.1.topicbox.com=fail (message has been altered)) (Message modified while forwarding at Topicbox) X-Received-Authentication-Results: authmilter.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC Policy is not at enforcement); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=OiNiV0Ao header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; iprev=pass smtp.remote-ip=209.85.167.49 (mail-lf1-f49.google.com); spf=pass smtp.mailfrom=rminnich@gmail.com smtp.helo=mail-lf1-f49.google.com; x-aligned-from=pass (Address match); x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=eQ4yi8O8; x-me-sender=none; x-ptr=pass smtp.helo=mail-lf1-f49.google.com policy.ptr=mail-lf1-f49.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com); x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com); x-tls=pass smtp.version=TLSv1.3 smtp.cipher=TLS_AES_128_GCM_SHA256 smtp.bits=128/128; x-vs=clean score=-100 state=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h= mime-version:from:date:message-id:to:content-type:list-help :list-id:list-post:list-subscribe:reply-to:subject :content-transfer-encoding:list-unsubscribe; s=dkim-1; t= 1767744221; x=1767830621; bh=cBNy+XuC+Xp7GXsVr05C1cy5q9rBR9lzjC+ lrofR+8s=; b=o0H1M0udY1hLorUtryJC8QZZwKJgHBCm1ojewkUPcdu0lzaV0h7 nk63588nWnfdvQmQH5c86doSv1VlwLK72ECByRXePojawTTHGFiG8ak4iUQ4oP4u 0sEvVwvgpN8TK3JOybo7fN+IH37KynevmOv8cFRPtQL6WIzxEFsr3Krs= Received: from authmilter.topicbox.com (unknown [172.17.0.1]) by mx.topicbox.com (Postfix) with ESMTP id CAE9F4D86406 for <9fans@9fans.net>; Tue, 6 Jan 2026 18:14:00 -0500 (EST) Received: from mx.topicbox.com (172.17.0.1 [172.17.0.1]) by authmilter.topicbox.com (Authentication Milter) with ESMTP id AE84D53FBA0; Tue, 6 Jan 2026 18:14:00 -0500 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t= 1767741240; b=VdSdC6zZg4u6rU10eMxs7k11fkD9polEj9G+O29JXlQQnIUpNA 4Gxu+QFVUueeq8j8i+qfxdxOppwGIlNSFY34UyH2mWpZlfrpaguxfIYoIO3u9e98 2LovSGQWusG5Yw0Of+pKMCfbPBU3U18Dqycs23FAuyJ4mao2xhHVoZpgQCjL8VXU KgaHeVN5shysV3q76wGTQESd06FQyn1DKtfw+zT+j9/kkUhIWmjYAIuoLdSHkdrM iSrJlVlQ/R5GozXOz0QfqDPquK60hgzYCgCXkQk5RtSBW6+VRgw4jGhA/8874t3+ H/wqlU6ZUFdKBw34QTCkIbh+H5xxJcGBGH+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=mime-version:from:date:message-id:subject:to :content-type; s=arcseal; t=1767741240; bh=FQ9IdXDnaftA8lIqSfvl+ 2/KQSAphNPaIq41LmZN15o=; b=mnaitCVpQdfupz1Jdnx7ZO56YxsQ6hpCjgvVr NGiwBJFWHzk9cm41QAn8iQ5eW/NLoWFv5kFqdmd886UhPjEj92+yYEBjKwzdTVxA Pizxw+2I1xE9wrvCZi/jOD5oCacthGi2xLBeZYMZRUFxBtC3YB1Dgc2SGO6BLM6i vzq6HUAYQJJjUfUxdNDCA8oYvkEvj/efs9xorJI+f81OZFrHr5DbIiaiQ+wOrd1K MG+UkMXml6NQHnpQs48M1sbGfK8mQEVo4Fs/VUODBe9V7aS8+XcZZJHox2jS1lrf 1GM09VKLzqsWNdDWxgVYSpuf+B0VIVvJfjbaaXjHnQfPD7hDg== ARC-Authentication-Results: i=1; authmilter.topicbox.com; arc=none (no signatures found); bimi=skipped (DMARC Policy is not at enforcement); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=OiNiV0Ao header.a=rsa-sha256 header.s=20230601 x-bits=2048; dmarc=pass policy.published-domain-policy=none policy.published-subdomain-policy=quarantine policy.applied-disposition=none policy.evaluated-disposition=none (p=none,sp=quarantine,d=none,d.eval=none) policy.policy-from=p header.from=gmail.com; iprev=pass smtp.remote-ip=209.85.167.49 (mail-lf1-f49.google.com); spf=pass smtp.mailfrom=rminnich@gmail.com smtp.helo=mail-lf1-f49.google.com; x-aligned-from=pass (Address match); x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=eQ4yi8O8; x-me-sender=none; x-ptr=pass smtp.helo=mail-lf1-f49.google.com policy.ptr=mail-lf1-f49.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com); x-return-mx=pass smtp.domain=gmail.com policy.is_org=yes (MX Records found: alt3.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt1.gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com); x-tls=pass smtp.version=TLSv1.3 smtp.cipher=TLS_AES_128_GCM_SHA256 smtp.bits=128/128; x-vs=clean score=-100 state=0 X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddutddugeekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepggfhfffkuffvtgesrgdtreertddtjeenucfh rhhomheprhhonhcumhhinhhnihgthhcuoehrmhhinhhnihgthhesghhmrghilhdrtghomh eqnecuggftrfgrthhtvghrnhepledtffdtudejgfetueekfeefueefheeftddtgefhvdef gfdvjeeuuedttefgtdefnecukfhppedvtdelrdekhedrudeijedrgeelnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvddtledrkeehrdduieejrdegledp hhgvlhhopehmrghilhdqlhhfuddqfhegledrghhoohhglhgvrdgtohhmpdhmrghilhhfrh homhepoehrmhhinhhnihgthhesghhmrghilhdrtghomheqpdhnsggprhgtphhtthhopedu pdhrtghpthhtohepoeelfhgrnhhsseelfhgrnhhsrdhnvghtqe X-ME-VSScore: -100 X-ME-VSCategory: clean Received-SPF: pass (gmail.com ... _spf.google.com: Sender is authorized to use 'rminnich@gmail.com' in 'mfrom' identity (mechanism 'include:_netblocks.google.com' matched)) receiver=authmilter.topicbox.com; identity=mailfrom; envelope-from="rminnich@gmail.com"; helo=mail-lf1-f49.google.com; client-ip=209.85.167.49 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx.topicbox.com (Postfix) with ESMTPS for <9fans@9fans.net>; Tue, 6 Jan 2026 18:14:00 -0500 (EST) Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-59b6f52eea8so149560e87.3 for <9fans@9fans.net>; Tue, 06 Jan 2026 15:14:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767741238; x=1768346038; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FQ9IdXDnaftA8lIqSfvl+2/KQSAphNPaIq41LmZN15o=; b=eQ4yi8O8b+c9zcKAiBaSqzey6S3P6H7X9tJ5tJ/vQSg9Ox3HVSDveQmAJ23Wuq4ij6 LOcAmdhOxMQSLr9E1imZUtVfODIAEhOvUOMcSaFRpoZpcSNBLFU24a7/LLQI++CRj23n YcbTuY+d7yNO/fBwDSOcQhvfVlku6+1mHuCrvVRjMczHZAyFoqvX0UU5TndSyYsjSD6N 2k+8Z5Cp5BVqxT6EJbw68umgVa1eD7yaEwrPSSm83XIW1UZpbjz7ByDlglxRpA/v8QiA KBdkbb5eJqFnHtMGFfj32gtL8uvCwCggug6RAa6RbLJDs5ygjvlBYnvwszyqki+nRwAo NjdA== X-Gm-Message-State: AOJu0YxKYSNrfSAQO5gfRIfiI/msaSgDJo7kfb4XWiJ+M8JFPPQt2gY3 neDsye8PcN/zPIGx0C1sOm2g1YXd8TtT+3ZvdkKY8yPLMYIaGbn0b8kmq3L15k+mTEF8228bFNy 1WFhhOqW5SXnFgaVeWq5POt6A5rBQj/Qs3g== X-Gm-Gg: AY/fxX5g5rzsl1mx2yQMZy5dz7/xBjFcuuOdbQvtJBQqEvX19sKz2SYt+SH0TI/IFRy P+02C6QNKtNsPUbKpUp7c4aWA2yZSJd7mpzYtCeEmVYBRrTlfFOjqIUBWZm4NwNtMAFpAU4JPM5 DKKvMtJIey0jODR1FFvgw0zkXOx7qLsq+qQCLG/JYOCZlkoZp7Y3PyG2/EFh8n91tPxQVw+3cKX TWfd6+ltu0TTot2wv5lMA4yr2WZtkdtWD1xdbvhuVj+j7Y3d1k8yvTuc3aEJYv1Z8R9FFtj X-Google-Smtp-Source: AGHT+IGfZ/9E2JGNSVstmJtP0WQgoAwtfcvHx3F0Mr+4vbwk7DWiZ+fHS0BbRocj4ZBlRcBFUL4tl0/DIjmsXVGfxyY= X-Received: by 2002:ac2:4d11:0:b0:59b:6fa8:bc8e with SMTP id 2adb3069b0e04-59b6fa8bee1mr65108e87.7.1767741237379; Tue, 06 Jan 2026 15:13:57 -0800 (PST) MIME-Version: 1.0 From: ron minnich Date: Tue, 6 Jan 2026 15:13:45 -0800 X-Gm-Features: AQt7F2r0TcZXXGW_6DdbxiS6WbZgGcZOijuKRR6RJSE4jrnto-Vo-b0lMzyett4 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0000000000008244810647c054f6 Topicbox-Policy-Reasoning: moderate: sender is a member; group holds all messages Topicbox-Message-UUID: 6322acea-eb55-11f0-86b3-55556cc11ef0 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UZjZlMGIxYjNmODBkZjgyMS1NNjcxMzY4NTJmMzY0ZjMzMzAwNGI3?= =?UTF-8?B?ZGIwPg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> Subject: [9fans] risc-v memory layout Content-Transfer-Encoding: 7bit List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M67136852f364f333004b7db0:1:0750Mb1mwmdvd_AkCVW4ALwqiZ749mSozqDN3yxOwsk --0000000000008244810647c054f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Something RIchard Miller said has got stuck in my head. I am wondering about memory layout on riscv64. The old tradition of "kernel at bottom of physical, top of virtual" is something we've always done. But do we have to? There are good riscv reasons to flip this. M mode, for example, has no virtual addressing, and it would be useful (to say the least) to have kernel and M mode have a common set of addresses. Further, the PMP registers, which can be used to manage/limit physical memory accesses, only gate addresses: they don't come with an offset. If we had kernel addresses that were 0-based and identity mapped, then the addresses would be the same for kernel, M mode, PMP, and IOMMU. A convenience of the "kernel in high memory" was the fact that an immediate 32-bit number, e.g. 0x80000000, sign extends to 0xffffffff_80000000, such that you can address a KVA with a 32-bit immediate, and a UVA with a 32-bit immediate, as long as it is < 0x80000000. But this comes with a headache: KVA breaks into a 2G region and "the rest", so you end up with two kernel VA ranges. It's annoying at least. The sign extend hack was convenient when 2G was a lot of memory, but after that, it's a bit of a pain. Finally, FWIW, loading a risc-v register with 0x4000_0000_0000_0000 is one instruction, so having a big number for a base virtual address is not the issue it is on amd64 (amd64 is, in many ways, a 32-bit architecture with a 64-bit RAX -- it is SO WEIRD, but it had to be to make the heroic move to 64 bits). So, the proposal: on riscv64, kernel address are 0 to (1<<62)-1, and user addresses are 1<<62 to (1<<62)-1. This means valid addresses are always int64, but will never be negative; we can keep using u64int. 62 bits of address space ought to be enough for everybody. Again, this makes a lot of RISC-V things easier. It would make it much easier to use kernel addresses for M mode code, because no translation would be needed, and a bunch of other risc-v mechanisms would be similarly simplified. I'm not sure the toolchain can handle having user text start at 0x4000_0000_0000_0000, but maybe it's not so hard: for gvisor, back in 2014, Russ added the code to 6l to allow us to link text in very high memory. So it has to be doable. The code's there in go1.4 :-) Comments? ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-M67136= 852f364f333004b7db0 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --0000000000008244810647c054f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Something RIchard Miller said has got stu= ck in my head. 

I am wondering about memory layou= t on riscv64.

The old tradition of "kernel = at bottom of physical, top of virtual" is something we've always d= one. 

But do we have to? There are good ris= cv reasons to flip this. M mode, for example, has no virtual addressing, an= d it would be useful (to say the least) to have kernel and M mode have= a common set of addresses. 

Further, the P= MP registers, which can be used to manage/limit physical memory accesses, o= nly gate addresses: they don't come with an offset. If we had kernel ad= dresses that were 0-based and identity mapped, then the addresses would be = the same for kernel, M mode, PMP, and IOMMU.

A c= onvenience of the "kernel in high memory" was the fact that an im= mediate 32-bit number, e.g. 0x80000000, sign extends to 0xffffffff_80000000= , such that you can address a KVA with a 32-bit immediate, and a UVA with a= 32-bit immediate, as long as it is < 0x80000000.

=
But this comes with a headache: KVA breaks into a 2G region and "= the rest", so you end up with two kernel VA ranges. It's annoying = at least. The sign extend hack was convenient when 2G was a lot of memory, = but after that, it's a bit of a pain.

Finall= y, FWIW, loading a risc-v register with 0x4000_0000_0000_0000 is one instru= ction, so having a big number for a base virtual address is not the issue i= t is on amd64 (amd64 is, in many ways, a 32-bit architecture with a 64-bit = RAX -- it is SO WEIRD, but it had to be to make the heroic move to 64 bits)= .

So, the proposal: on riscv64, kernel address a= re 0 to (1<<62)-1, and user addresses are 1<<62 to (1<<62= )-1. This means valid addresses are always int64, but will never be negativ= e; we can keep using u64int. 62 bits of address space ought to be enough fo= r everybody.

Again, this makes a lot of RISC-V t= hings easier. It would make it much easier to use kernel addresses for M mo= de code, because no translation would be needed, and a bunch of other risc-= v mechanisms would be similarly simplified.

I= 9;m not sure the toolchain can handle having user text start at 0x4000_0000= _0000_0000, but maybe it's not so hard: for gvisor, back in 2014, Russ = added the code to 6l to allow us to link text in very high memory. So it ha= s to be doable. The code's there in go1.4 :-)

Comments?



<= /html> = --0000000000008244810647c054f6--