jay321 has quit [Remote host closed the connection]
kilobyte_ch has quit [Ping timeout: 240 seconds]
heat has quit [Read error: Connection reset by peer]
heat has joined #riscv
jacklsw has joined #riscv
kilobyte_ch has joined #riscv
aredridel6 has joined #riscv
Trifton has joined #riscv
aredridel has quit [Ping timeout: 248 seconds]
aredridel6 is now known as aredridel
billchenchina has joined #riscv
heat has quit [Remote host closed the connection]
heat has joined #riscv
jacklsw has quit [Quit: Back to the real world]
jacklsw has joined #riscv
jay321 has joined #riscv
heat_ has joined #riscv
heat has quit [Remote host closed the connection]
jay321 has quit [Remote host closed the connection]
jay321 has joined #riscv
heat_ has quit [Ping timeout: 260 seconds]
EchelonX has quit [Quit: Leaving]
BootLayer has joined #riscv
ashtin has joined #riscv
<pierce>
I have probably a terribly dumb question. But when a system is sv39, what needs to change for it to become sv48?
<jay321>
"9 things"!
<jay321>
...sorry man
<jay321>
When a system is sv39, the following things need to change for it to become sv48, "The kernel needs to be compiled with sv48 support, The boot loader needs to be configured to use sv48, The root filesystem needs to be formatted with an sv48-compatible filesystem, The userland applications need to be compiled with sv48 support." Once these changes have been made, the system can be booted into sv48 mode.
<jay321>
this was from bard
<thefossguy>
Google’s bard?
<jay321>
yes
<thefossguy>
Ok
ashtin has quit [Quit: Leaving]
vagrantc has quit [Quit: leaving]
<pierce>
Interesting, so there'd have to be a full new build of the distro to support sv48
<pierce>
Are there any sv48 distros going around?
billchenchina has quit [Remote host closed the connection]
<muurkha>
jay321: is that bullshit?
billchenchina has joined #riscv
<jay321>
what ?
<muurkha>
the stuff Bard said
<muurkha>
Bard says a lot of bullshit
<jay321>
i dont know
<muurkha>
is that bullshit?
<muurkha>
if you don't know then why did you paste it?
<jay321>
because maybe it helps
<muurkha>
how would it help if you don't have any reason to believe it's true?
<jay321>
it sounds correct, but if the answer goes no where, mine as well write it and attribution
<muurkha>
my experience with LLMs is that they very often say things that sound right but are very wrong, like journalists
<muurkha>
often in the sort of subtle ways that can waste a lot of your time
tanyastopguy has joined #riscv
<muurkha>
I think of them largely as automating trolling
<muurkha>
(though if you get stuck, they can provide all kinds of creative things to try, sure)
<jay321>
sometimes you ask irc networks something and there is no response, so asking the chatbots fills in some of the white noise
<pierce>
muurkha: i don't think anyone should or would accept whatever chatgpt or whatever to say as gospel
<muurkha>
'noise' is another word for 'trolling'; what distinguishes noise from signal is literally that the noise is unwanted
<jrtc27>
what you posted is 90% bullshit
<jrtc27>
if you don't know, don't answer
<jrtc27>
regurgitating AI-generated bullshit is not of any use
<jrtc27>
at best it's useless, at worst it's harmful
<jay321>
ok, what was the answer, im curious now
<jrtc27>
depends whether we're talking hardware or software
<jrtc27>
hardware needs to grow support for an extra level of page table walking
<jrtc27>
(and potentially more address bits)
kilobyte_ch has quit [Ping timeout: 256 seconds]
<jrtc27>
software needs a kernel that configures the hardware to use an extra page table level
<jrtc27>
that's about it
<jrtc27>
boot loaders don't deal with page tables (mostly)
<jrtc27>
root filesystems have nothing to do with page ables
<jrtc27>
userland normally doesn't care, unless it's making assumptions that it can fit addresses into X < 48 bits
<muurkha>
or unless the page size changes, which it doesn't normally
<jrtc27>
that's orthogonal
<jrtc27>
(yes, I know in aarch64 it's slightly not)
<muurkha>
I didn't know that
<muurkha>
but it did occur to me that it could happen on some architecture
<muurkha>
but probably I shouldn't have mentioned it
kilobyte_ch has joined #riscv
<zBeeble24>
a pertinant example would be emacs. The lisp interpreter in emacs _used_ to pack the type of the variable into 4 bits of the pointers (This is from memory --- could be 2, 3 or 8). Point is, for UN*X, this worked fine as the app always started in the same address in virtual memory.
<zBeeble24>
... I recall all this from porting emacs to the Amiga --- without virtual memory, this little assumption was in danger.
<zBeeble24>
I believe this was true around emacs version 18 (again from memory, not looking it up)
aredridel9 has joined #riscv
aredridel has quit [Ping timeout: 240 seconds]
aredridel9 is now known as aredridel
<pierce>
<jrtc27> "userland normally doesn't care..." <- Shouldn't care
aerkiaga has quit [Remote host closed the connection]
TMM_ has joined #riscv
awita has quit [Ping timeout: 268 seconds]
ffcc has joined #riscv
foton has quit [Read error: Connection reset by peer]
foton has joined #riscv
Andre_Z has joined #riscv
Trifton has quit [Quit: Error: no route to host]
Trifton has joined #riscv
_whitelogger has joined #riscv
jacklsw has joined #riscv
jay321 has joined #riscv
terminalpusher has joined #riscv
Trifton has quit [Remote host closed the connection]
Trifton has joined #riscv
KombuchaKip has quit [Quit: Leaving.]
Trifton has quit [Ping timeout: 264 seconds]
<zBeeble24>
muurkha: It did care about about the number of significant bits in a pointer.
<zBeeble24>
I don't think GPT-4 got it right nearly at all. Your kernel needs to setup and manage sv48 vs. sv49. It's unlikely your loader or your filesystem or your userland changes. I suppose it depends where you draw the line --- the loaded portion of the kernel (which can sometimes be sacrificial) is where you might setup the MMU for the first time --- but that's still (to me) a sv48 aware kernel.
aredridel7 has joined #riscv
<bjdooks>
for the kernel, the svXX changes the number of pagetable layers needed, as you get more svxx you need more levels, so even if you don't yse the top levels you need it there for the pgtable code
<bjdooks>
s/code/hardware/g
aredridel has quit [Ping timeout: 256 seconds]
aredridel7 is now known as aredridel
juliadev has quit [Read error: Connection reset by peer]
juliadev has joined #riscv
MaxGanzII_ has quit [Ping timeout: 240 seconds]
ldevulder has quit [Quit: Leaving]
ffcc has quit [Quit: Leaving]
MaxGanzII_ has joined #riscv
jacklsw has quit [Read error: Connection reset by peer]
Narrat has joined #riscv
vagrantc has joined #riscv
<zBeeble24>
right ... I wasn't saying what the kernel needed (although I do know that) ... in responding to the earlier chat I was saying that the CHAT-GPT list of things needed for a sv48 distribution was plainly wrong.
pedja has joined #riscv
<zBeeble24>
... although a good point here is that the changes required for a kernel to support sv48 are (relative to the kernel) small. In fact, it's entirely feasible for a single kernel to support both sv39 and sv48.
<courmisch>
is it? on arm64, you need to select it at build time, IIRC
<zBeeble24>
Modern portable operating systems must have the MMU as a architecture specific piece, but more than that... to support 486, pentium and "686" in one kernel, you need to have the boot process probe the kernel and select the right MMU code.
<courmisch>
because for hysterical raisins, the kernel wants to statically unroll the page table management code with a fixed depth
awita has joined #riscv
<zBeeble24>
well... you might compile it in or not as an option (ie: removing support). Certainly it's possible for a kernel to support both (I'm a FreeBSD guy and not a Linux guy).
billchenchina has joined #riscv
<courmisch>
no question that it's possible to write the software to support however many different configurations
<zBeeble24>
for the '86 family linux absolutely supports multiple organizations of memory (it has to).
<courmisch>
on arm64 you have to choose 48 or 39 bits AS at build time
<courmisch>
and you can't use different sizes for top and bottom halves
<zBeeble24>
... so whether or not it does for RISC-V is just a choice. The existance of an option to compile in SV48 doesn't mean that it doest then work on SV39 (you'd have to look at the docs for that).
<courmisch>
(on Linux; obviously VMSA supports dynamic configuration)
<zBeeble24>
... which was the original incorrect portion of the CHAT-GPT answer.
<courmisch>
welllllll, you could write shitty software that breaks if the address space is bigger or smaller than expected
<courmisch>
more commonly, assuming that page size is 4K
<zBeeble24>
actually, most processor families have wildly differing MMUs version-to-version.
<zBeeble24>
userland? I mean you _could_ contrive a problem with 4k pages --- but you're probably writing code that would break in a lot of ways.
<zBeeble24>
... but it's not easy.
jobol has joined #riscv
<courmisch>
I don't write that kind of code, but judging by the problems with Asahi Linux, it's quite a common mistake
<courmisch>
I think the browsers just wouldn't handle non-4K pages
<zBeeble24>
and, at least on FreeBSD, variable sized pages ("superpages") have existed for about ... urm... 5 years? More? again ... just from memory --- a long time.
handsome_feng has quit [Quit: Connection closed for inactivity]
<zBeeble24>
nope. Browsers absolutely work on BSD. And windows. Windows definately uses non-4k pages.
<zBeeble24>
In fact, I'd be surprised if linux didn't do non-4k pages for some time now --- it's performance would badly suck without superpages.
<courmisch>
Chromium didn't support 16K until recently
<zBeeble24>
In fact, on FreeBSD, Windows and I suspect Linux, you can be allocated a number of 4k pages ... which are then later promoted (say) to a 128k page ... transparently.
<zBeeble24>
I call horsehockey. FreeBSD and Windows both have had pages that scale well beyond 16k for ... years. Since at least win10 and FreeBSD 10.
<courmisch>
using grouped pages or large pages is irrelevant to compatibility; it just means you'll get better performance if you specifically use higher alignment
<zBeeble24>
Gotta be some other thing your thinking of... Gimme URL.
<zBeeble24>
man... that's just linux damage. Wow. So the problem here is that the fiefdoms don't align and you don't have overall design strategy.
billchenchina- has joined #riscv
<zBeeble24>
... this isn't chromium not supporting it ... it's your toolchain producing something your ABI doesn't support.
<another|>
there was some problem with go programs and sv57 since go uses those bits for something else. not sure if it's fixed yet
<courmisch>
pointer tagging?
<zBeeble24>
... that is covered in my emacs thing. It's bad to used bits of pointers.
<zBeeble24>
NB: doesn't break with sv57, but simply with anything that uses those bits of pointers.
<zBeeble24>
broke without even an MMU on the Amiga ... simply from having memory there.
billchenchina has quit [Ping timeout: 240 seconds]
zBeeble24 is now known as zBeeble
<courmisch>
zBeeble24: you're splitting hairs. Obviously it can't be that many places that depend on page size in user spaces. Of course it's going to be some "misconfiguration"
<zBeeble>
Well... no. It's entirely possible to produce a distribution that works on all ... simply by allgning your sections in your binaries to the largest possible page size _or_ by making y our loader smarter.
<dh`>
pointer tagging is an old and well-established technique
<dh`>
people who do it wrong deserve the consequences
<zBeeble>
There really arn't many places that depend on page size. This bit is just your toolchain being dumb. Binaries that work everywhere were possible (and not dependant on any code the developer wrote) ... your toolchain fiefdom was just too shortsighted to not make that happen.
<zBeeble>
pointer tagging is an unsupported and only randomly works hack for compression of structures. Pointer tagging is fantastically unportable.
<courmisch>
dh`: there's no standard on how many bits you can use, even if it's a well-known trick
<dh`>
right, which is why it has to be configured based on the target
<zBeeble>
It's up there with the "nobody will need more than 640k" quote.
<dh`>
and furthermore, on a 64-bit machine just ordinary pointer alignment gives you three bits, which is plenty for most scheems
<dh`>
or schemes
<zBeeble>
sure there is. it's called your ABI ... and I doubt it says anything other than "a pointer is x bits" ... the fact that you find that you can use a few is a _hack_.
<courmisch>
dh`: there's an API to fetch the page size, but I don't recall a standard API to retrieve the address space size
<zBeeble>
oh... you're going to use the low three bits. Entertaining. That breaks so many things (that say access less than 64 bit things)
* dh`
sighs
<dh`>
have you ever written an interpreter or compiler?
<zBeeble>
you can ask a machine what it's page size is. It's a moving target --- as superpages are common now.
<zBeeble>
yes.
<zBeeble>
both.
<dh`>
i'm sorry to play the "you just don't konw what you're talking about" card but i don't have the energy to argue this point
<zBeeble>
And for several binary types.
<zBeeble>
I didn't say you can't or even shouldn't, I'm just saying it's a hack and it's largely unportable.
<zBeeble>
About the only thing I haven't done in this discussion is to implement MMU code directly --- although I have debugged it on FreeBSD.
<dh`>
of course it's unportable, _generating code_ is unportable too or hadn't you noticed?
<dh`>
as a compiler writer you get complete control over things like alignment of data items
<zBeeble>
Well... ok ... getting into the weeds here, but ... urm... my point is you have an ABI given to you by your operating system. There's the ABI that it officially documents and then there's the ABI of what works.
<courmisch>
for a very broad definition of "complete control"
<dh`>
as an interpreter writer you get less control over some things and more over others
<zBeeble>
... generally (although not always) scraping point bits is in the "what works" not the "what's documented" ... and thusly, fairly, the kernel is free to start rejecting your hack at any point.
<dh`>
where does the kernel come into this? we were talking about an interpreter running in userland a moment ago
<courmisch>
dh`: if the kernel decides to expand the address space size, then what upper bits you thought you could use, you no longer can
<zBeeble>
I mean: look at what you're doing ... your saying that these pointer bits are always "this pattern" (note: not just zero, but some pattern, normally) ... and they only reason you can say that is ... observing the system in it's current configuration ... I only see those patterns.
<courmisch>
unless you have a mean to explicitly agree with the kernel (such as how you can explicitly control the top bit on Armv8)
<courmisch>
top byte*
<dh`>
courmisch: I said nothing about upper bits, assuming current memory sizes will never increase is obviously stupid
<dh`>
also gives you code that won't even build on a 32-bit machine let alone run.
<zBeeble>
... so if the kernel mmap()'s you some space there or sbrk()'s you some space there --- (we're talking kernel calls, I suppose, not malloc) ... then you now have space there. Did the kernel tell you it would never do that?
<courmisch>
dh`: pointer tagging is usually done with upper bits. Arm, and more recently Intel and AMD started supporting that explicitly
<courmisch>
though I agree that if you control alignment you can scrap a few lower bits
<zBeeble>
call pointer tagging what it is: a simple hack to compress the size of a data value for your program (be it interpreter or whatever). It's a compression hack.
<dh`>
on a 32-bit machine you can't use upper bits and that's been true for decades
<dh`>
so I can't agree
<dh`>
there were some 32-bit machines where you could use the uppermost bit, but lots where you couldn't even in the 90s
<courmisch>
I'm not sure what it means to disagree with a specification
<zBeeble>
well yeah... on a 32 bit machine ... address spaces grew to 4G faster than anticipated. Using the whole 64 bit space is a bit much now ... but so was using the whole 32 bit space when I had a sun4/260 in my home office.
<dh`>
from what I recall, sunos4 placed the stack growing down from 0x7fffffff like everyone else
<zBeeble>
emacs used either 3 or 4 bits ... in a 32 bit environment... version 16 to 18 or so was when I was hacking on it.
<zBeeble>
I ran NetBSD on it at-the-time. Was about 1995.
<dh`>
judging from the scroll, I think you have forgotten some of the issues
<zBeeble>
but the fact that I had 4 32meg ram boards was considered "wow" for the system.
<dh`>
the problem with undump on the amiga isn't pointer tagging, it's the address of the dump region getting baked in
<zBeeble>
... although by 95, PC's had that much memory too.
<zBeeble>
well... the Amiga's problem is that while some amiga's had MMUs (I had an 030, for instance) ... the memory addresses were "real" ... and so memory could exist in several places that would violate the emacs assumption.
<zBeeble>
emacs ran just fine if I loaded netbsd up on my amiga... engaged the MMU. That's just not fun, tho.
<dh`>
no, you could configure emacs to use whatever bits as the tags (though it was a pain in the ass, iirc)
<zBeeble>
I actually had software on AmigaOS that used the MMU to protect memory (didn't change it's location ... just engaged the protection bits) ... heh. old times.
<dh`>
so absent a seriously pathological memory map or far more ram than anyone actually had in those days you could fit them somewhere
<zBeeble>
dh: you could, but in many amiga configs, there weren't bits to be found there ... just because there was enough memory at enough different positions to flummox the scheme
<dh`>
that I don't remember
<dh`>
anyway the undump problem is much more serious
<zBeeble>
which is where I return to "it's a hack" ... hacks are neither good nor bad. They work when they work and the break when they break. IFF, say, someone on some platform is writing down in the ABI (the documented ABI) that pointers are less than the given bits --- then it's not a hack. Otherwise, by definition (something undocumented, but generally working and useful) ... it's a hack.
<zBeeble>
undump problem?
<dh`>
<dh`> the problem with undump on the amiga isn't pointer tagging, it's the address of the dump region getting baked in
<zBeeble>
oh... emacs undump... yeah.. made that work. Was easy. Just made undump act like a loader.
<dh`>
amigaos doesn't promise you a fixed load address (and had/has no way to)
<zBeeble>
... so it just applied offsets to the pointers. Was actually pretty simple.
<dh`>
furthermore, it doesn't even promise you a contiguous region of memory you can dump from
<dh`>
so you first have to hack that
<zBeeble>
well... my emacs loader would handle a few memory regions ... I think I made 128k allocations to move in the code.
<zBeeble>
but emacs worked without my hack --- you just had to run through the initial load when you started it. 20 or 30 seconds or so --- but if you left your emacs running for days ... that wasn't a big thing.
<dh`>
run yes, work properly no, at least in that era emacs expected to be dumped and wouldn't give you the right entry points if you didnt' dump it
<dh`>
anyway, w/e.
<dh`>
the fact remains: pointer tagging is an old and well-established technique
<dh`>
if people make stupid assumptions when implementing it, all you can say is that they should have known better
<dh`>
given that we're into arguing about details of a 30-year-old implementation
BootLayer has quit [Quit: Leaving]
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #riscv
terminalpusher has quit [Remote host closed the connection]
Andre_Z has quit [Quit: Leaving.]
terminalpusher has joined #riscv
aredridel0 has joined #riscv
aredridel has quit [Ping timeout: 240 seconds]
aredridel0 is now known as aredridel
<Tenkawa>
Esmil: do you know if the 6.4-rc kernel is capable of running as is now in mainline?
<Tenkawa>
Esmil: specificly on the VisionFive2
elastic_dog has quit [Remote host closed the connection]
elastic_dog has joined #riscv
bauruine has quit [Remote host closed the connection]
<courmisch>
dh`: I only heard the term used for upper bits, but yes it has worked fairly portably on the lower bits, if you know what you're doing with alignment
<courmisch>
though in principles, that only works in assembler and generated code. Casting a non-pointer value to a pointer is nominally undefined in C and friends
prabhakarlad has quit [Quit: Client closed]
PobodysNerfect_ has quit [Quit: Gone to sleep. ZZZzzz…]
<dh`>
it is not undefined, it's implementation-defined
<dh`>
well, casting arbitrary integers to pointers and using them is undefiend
<dh`>
but casting a pointer to a sufficiently large integer and back is guaranteed to work, and mucking with the integr value as long as the transformation is invertible and inverted properly can only affect that in implementations that track pointer provenance
<dh`>
I don't know what happens with pointer-tagging implementations on cheri, but I'm sure jrtc27 does
jobol has quit [Quit: Leaving]
<dh`>
(contrary to what zBeeble thinks, pointer tagging is common enough that there might be explicit support for it)
<jrtc27>
"it depends"
<jrtc27>
depends on what you're trying to tag, and on what architecture
<jrtc27>
and which bits you're trying to us
<jrtc27>
*e
terminalpusher has quit [Remote host closed the connection]
terminalpusher has joined #riscv
elastic_dog has quit [Remote host closed the connection]
elastic_dog has joined #riscv
awita has quit [Remote host closed the connection]
billchenchina- has quit [Ping timeout: 240 seconds]
unsigned has joined #riscv
billchenchina- has joined #riscv
wingsorc has joined #riscv
Leopold has joined #riscv
Narrat has quit [Quit: They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.]
unsigned has quit [Quit: .]
unsigned has joined #riscv
wingsorc has quit [Remote host closed the connection]
jay321 has quit [Read error: Connection reset by peer]
elastic_dog is now known as Guest6504
Guest6504 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
elastic_dog has joined #riscv
jay321 has joined #riscv
wingsorc has joined #riscv
prabhakarlad has joined #riscv
elastic_dog has quit [Killed (molybdenum.libera.chat (Nickname regained by services))]
elastic_dog has joined #riscv
MaxGanzII_ has quit [Ping timeout: 240 seconds]
jay321 has quit [Remote host closed the connection]
aredridel4 has joined #riscv
billchenchina- has quit [Ping timeout: 240 seconds]
aredridel has quit [Ping timeout: 248 seconds]
aredridel4 is now known as aredridel
terminalpusher has quit [Remote host closed the connection]