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,RCVD_IN_ZEN_BLOCKED_OPENDNS, URIBL_DBL_BLOCKED_OPENDNS,URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=3.4.4 Received: from txout-a4-smtp.messagingengine.com (txout-a4-smtp.messagingengine.com [103.168.172.227]) by inbox.vuxu.org (Postfix) with ESMTP id C772D256F3 for ; Wed, 7 Jan 2026 21:12:24 +0100 (CET) Received: from localhost.localdomain (phl-topicbox-01.internal [10.202.2.219]) by mailtxout.phl.internal (Postfix) with ESMTP id 775041C029A for ; Wed, 7 Jan 2026 15:12:24 -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=bux7CYtX 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-f43.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:references:in-reply-to:from:date :message-id:subject:to:content-type:list-help:list-id:list-post :list-subscribe:reply-to:content-transfer-encoding :list-unsubscribe; s=sysmsg-1; t=1767816744; bh=UlFbs0JvqSWNfnHU un4zuM8kST1mZBaQ0ig7pPFHOqQ=; b=k6l2HV/+ByWRuOMhJz3T8vYKIO44OHBg xqdbptkb+Pva7lie2mOV1fTMGJQ2D4kS2oEs6GaheVOPpiFitrgmOFnk96ECK9WI u5h1MjPmK6XXYDRWESi6IEtkeDLP4PtJmHmuCl49jWQkb+NEOzqHGCgj3iYq2d3+ bTBMD1qgYSU= ARC-Seal: i=2; a=rsa-sha256; cv=pass; d=topicbox.com; s=sysmsg-1; t= 1767816744; b=m317t9+f+vIWY71tlQqQcaf9i3GP6DMxl1ulo/3n0qYsMrPZt3 quQeTvhdP3q5UZPLjse0eJc+qhAoXmZwLcM7onmoSqu/YE1zb2zDg9Uf+A9K9jNc 29wbExltG17KKPvFAtkqsaMlL6oATDUE1iKhc84o76FfLRfqgkVvQigHg= Authentication-Results: topicbox.com; arc=pass; dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=bux7CYtX 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-f43.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=bux7CYtX 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.43 (mail-lf1-f43.google.com); spf=pass smtp.mailfrom=rminnich@gmail.com smtp.helo=mail-lf1-f43.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=W5AYtxX6; x-me-sender=none; x-ptr=pass smtp.helo=mail-lf1-f43.google.com policy.ptr=mail-lf1-f43.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt2.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt1.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,gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt1.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=0 state=0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:content-type:list-help:list-id:list-post:list-subscribe :reply-to:content-transfer-encoding:list-unsubscribe; s=dkim-1; t=1767816744; x=1767903144; bh=JMikVf1Wz4Bfz3JOaXpoGfcn/c/c/ZDb Kl15H4fveMQ=; b=UyMqyrpr61inCRNtbITiuc+H/bnD082j5pEhJTP9kke6ioVa sz5X2KDldXl03X13tNe4cVqy77fcMbIhmexLAHzciW8my260C3LR6jl8PhyXUa5X 2I80JUM6j2huSC6l6ppQOCAF6wNdBTUeg/NO1qjZHDruT5hT0ClyD+ln9oo= Received: from authmilter.topicbox.com (unknown [172.17.0.1]) by mx.topicbox.com (Postfix) with ESMTP id 413E54D80531 for <9fans@9fans.net>; Wed, 7 Jan 2026 14:28:22 -0500 (EST) Received: from mx.topicbox.com (172.17.0.1 [172.17.0.1]) by authmilter.topicbox.com (Authentication Milter) with ESMTP id 6E790FEE518; Wed, 7 Jan 2026 14:28:22 -0500 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=topicbox.com; s=arcseal; t= 1767814102; b=AdxrlCLC9EZdkopw5pdQWihnDt9l+Z/GvYXKIknvtX5tWfmNgM ODNWPBVKvAABO2rWhE12jQi2pI1Q/J6rv6P9rLaWAFmJpOq/84lzYrjxIht8vhXY jVauWhyxLN4bMNOBV84FlMlY9ELq1BotSuzip4tvOOHEPKdlWg1anqoIwJhe8jS+ IlP/mPsc7lj3wWhhxE4132MI59GZKwW6xmguEVAb1Q3vSrMWUpsZNuoXYefMR9DW 7RIvAe4M8Y61BnrtDbAXHo6K4GYPAxzGWgxbuyuS6K26GtimZfg0aZ4WAeQXeyAe cyQ266UfbRxuy+LusnxG16WYEH7Mg1Y8Zggw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= topicbox.com; h=mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; s=arcseal; t=1767814102; bh=m52SsQcpoG83OFlyBmFgrrfpuzIyGkG4M9sQS4tqAlI=; b=vyujAEaoj67+ GC000lUAyGFvJNfPJt+qhpWdKeWJG+FTU/8N//avTUhRrIzAsg1rlwoYaLNhY60S PJlqcnKwT+mwkgEPmrwfTQkPLAGLCxSCnwSH9xdFxl4UkJc10Up/Ep8El/tyyymp /x11f5vPyWFVreOHhr0r79Z15OoEB7TdKzi522OjEku/4XiVXSmTAHt4ub51yVWx iWTwq4CLjOtMTaYONmEw9w2RtQX4iCubLxrlCwDZanceHYTDr/E8pvK+Lf07/Md2 2pGkQ7kC/dKTL36wQO1WfO+INJ7EH4AYtltM/lMoKB2W4LQKaTe1ThtJDD2IOIR6 eU4h0i3zIw== 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=bux7CYtX 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.43 (mail-lf1-f43.google.com); spf=pass smtp.mailfrom=rminnich@gmail.com smtp.helo=mail-lf1-f43.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=W5AYtxX6; x-me-sender=none; x-ptr=pass smtp.helo=mail-lf1-f43.google.com policy.ptr=mail-lf1-f43.google.com; x-return-mx=pass header.domain=gmail.com policy.is_org=yes (MX Records found: alt2.gmail-smtp-in.l.google.com,alt3.gmail-smtp-in.l.google.com,gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt1.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,gmail-smtp-in.l.google.com,alt2.gmail-smtp-in.l.google.com,alt4.gmail-smtp-in.l.google.com,alt1.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=0 state=0 X-ME-VSCause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddutdefledtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpeggfh gjhfffkffuvfgtsegrtderredttdejnecuhfhrohhmpehrohhnuchmihhnnhhitghhuceo rhhmihhnnhhitghhsehgmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeekgfdvfe efueeivddtueeftdeitdeltdekgeeujeehheevheeifeffgfefudetueenucffohhmrghi nhepkhgvrhhgihhsrdgtohhmpdhtohhpihgtsghogidrtghomhenucfkphepvddtledrke ehrdduieejrdegfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvght pedvtdelrdekhedrudeijedrgeefpdhhvghlohepmhgrihhlqdhlfhduqdhfgeefrdhgoh hoghhlvgdrtghomhdpmhgrihhlfhhrohhmpeeorhhmihhnnhhitghhsehgmhgrihhlrdgt ohhmqedpnhgspghrtghpthhtohepuddprhgtphhtthhopeeolehfrghnsheslehfrghnsh drnhgvtheq X-ME-VSScore: 0 X-ME-VSCategory: clean Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.167.43 is authorized to use 'rminnich@gmail.com' in 'mfrom' identity (mechanism 'ip4:209.85.128.0/17' matched)) receiver=authmilter.topicbox.com; identity=mailfrom; envelope-from="rminnich@gmail.com"; helo=mail-lf1-f43.google.com; client-ip=209.85.167.43 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) (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>; Wed, 7 Jan 2026 14:28:22 -0500 (EST) Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-59b7073f61dso1369117e87.2 for <9fans@9fans.net>; Wed, 07 Jan 2026 11:28:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767814100; x=1768418900; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=m52SsQcpoG83OFlyBmFgrrfpuzIyGkG4M9sQS4tqAlI=; b=W5AYtxX6z+NLsQFOqNZ2Nyhcevb/8qtJKOpKABLuf1LRvCHdNm86UyFWzeDYHP5ryy f8Llr1hiqDL35115CZiCob3cQjhTZfamgRxkbYATRcxdlNpssIpwNJj9G7WZbRaCiEAO EtpS3ChcwwVV26MrvQTngb13cgKY/UcsMnHXxNN2kLNwpltw2MG9Nmk6Qwparp84hkUL HiJpXOFZhl67m/R02b5rd4Czgtmm+tmegRYGq6pDAvfV8hDbpCQDLZ9vtMhlMCNi9cjR Y3GCG8pPgdH3eu+mt5QBXvVQ65bzvJ6piRHWN1uVgKVIlyf08T92aH8AuKIduSo8srLN 6RkQ== X-Gm-Message-State: AOJu0YxFU/gkqsO4o/AVdHdV6YtdZNz3w6VoKvp3AoA6w9uesZy2fxku juaqutElXHPmaV9ztnu5s8b4W6VbcShACeer042vRee5m1pFeU3WwZlv2V9P0lxsgOrtZkE26bG oRGKpw0LxSwSPRZ7jr6Cdhoga9QcqNLUCgA== X-Gm-Gg: AY/fxX7lvHlXJD4bxns17Q4lfKkv3jpDFww0jPKUzqZOwMHCQJbKUYZSS224NHnc2Ia 7Q2R9Gtgjkt/462loWwVKbYXhzykgFf1DsJEDgg4rDXt4/7wOvTETSSLzhtoqElcQ5dP80skc5+ 7m0swSeTUoB25iMQXlcxTMTvQpgm5cHmaumzO3EM09pnv/Zew7yZSo+mmAPZCN7bQfF+MIuAje+ 0HYoP5lzcdutNOyioeKJWUVMpiRQcMmhjF5VMwdT6Y1JrTwsLEYZ3fQIDvqEfR5mNQ2kHn9 X-Google-Smtp-Source: AGHT+IFuemalXO1ZgNS3FD2fx+c1BiqinMOZchvKh2LjXf6m+UONNtpWcfgLgom19xZW78CI9vcihomw2KCQhUXnjtE= X-Received: by 2002:a05:6512:3ca1:b0:598:8f92:c33e with SMTP id 2adb3069b0e04-59b6f0552e2mr1157134e87.50.1767814099556; Wed, 07 Jan 2026 11:28:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: ron minnich Date: Wed, 7 Jan 2026 11:28:04 -0800 X-Gm-Features: AQt7F2rNMQcTtKAD6_ZciXb3kvyKPvG2y18aKpXKw72rprVwrZNi-aI42ip4i90 Message-ID: Subject: Re: [9fans] risc-v memory layout To: 9fans <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0000000000006ee4e80647d14be1 Topicbox-Policy-Reasoning: moderate: sender is a member; group holds all messages Topicbox-Message-UUID: 07f1961a-ebff-11f0-9450-30686cc11ef0 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UZjZlMGIxYjNmODBkZjgyMS1NNjAwOGIzMmUwYThkMDhjOGQwZWJh?= =?UTF-8?B?ODNjPg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> Content-Transfer-Encoding: 7bit List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:M6008b32e0a8d08c8d0eba83c:1:etkrFK5mTAU5bWmG_2nU32MqGCJ1O2Zh7r3bOM_RdxU --0000000000006ee4e80647d14be1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't much like IOMMU on x86, they are just awful to program, and come with a performance hit. They're also here to stay. If you can disable x2apic on your amd, then you should be able to turn off iommu I believe? On Wed, Jan 7, 2026 at 9:58=E2=80=AFAM wrote: > Concerning IOMMU, what is the general position regarding it? I had > tested an AMD64 8 physical cores (for Nix eventually) but run into > problems regarding USB because IOMMU is not handled and apparently > recent firmware unable it by default so one has to put it out the > way---in my case, this is USB that was put out of the way, but it is > a PITA (keyboard...). So how does it usage fit regarding Plan9, Nix? > > On Tue, Jan 06, 2026 at 03:13:45PM -0800, ron minnich wrote: > > 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, f= or > > 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, su= ch > > 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 si= gn > > 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 t= he > > 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 us= er > > 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? >=20 > -- > Thierry Laronde > http://www.kergis.com/ > http://kertex.kergis.com/ > Key fingerprint =3D 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-M6008b= 32e0a8d08c8d0eba83c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --0000000000006ee4e80647d14be1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't much like IOMMU on x86, they are j= ust awful to program, and come with a performance hit. They're als= o here to stay. If you can disable x2apic on your amd, then you should be a= ble to turn off iommu I believe?

On Wed, Jan 7, 2026= at 9:58 AM <tlaronde@kerg= is.com> wrote:
Concerning IOMMU, what is= the general position regarding it? I had
tested an AMD64 8 physical cores (for Nix eventually) but run into
problems regarding USB because IOMMU is not handled and apparently
recent firmware unable it by default so one has to put it out the
way---in my case, this is USB that was put out of the way, but it is
a PITA (keyboard...). So how does it usage fit regarding Plan9, Nix?
<= br /> On Tue, Jan 06, 2026 at 03:13:45PM -0800, ron minnich wrote:
> 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 virtua= l" 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 offs= et. 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 th= at an immediate
> 32-bit number, e.g. 0x80000000, sign extends to 0xffffffff_80000000, s= uch
> that you can address a KVA with a 32-bit immediate, and a UVA with a 3= 2-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. T= he 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 wi= th 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 address= es are always
> int64, but will never be negative; we can keep using u64int. 62 bits o= f
> 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 simil= arly
> 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, bac= k in
> 2014, Russ added the code to 6l to allow us to link text in very high<= br /> > memory. So it has to be doable. The code's there in go1.4 :-)
>
> Comments?

--
        Thierry Laronde <tlaronde +AT+ kergis +dot+ = com>
                     = ;ht= tp://www.kergis.com/
                    http:= //kertex.kergis.com/
Key fingerprint =3D 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C=

------------------------------------------
9fans: 9fans
Permalink: https:= //9fans.topicbox.com/groups/9fans/Tf6e0b1b3f80df821-M1cd5f0159acc2ad51e61db= 64
Delivery options: https://9fans.topicbox.com/gro= ups/9fans/subscription
= --0000000000006ee4e80647d14be1--