Re:RISC-V OS Using Rust: Memory Management Unit
by comex on Monday November 04, 2019 @04:48PM
(#21446876)
> Obviously, I wasn't consulted when this was kicked around, and I haven't done my due diligence to look up potential reasons. So, I risk embarrassment to preserve my time :(.
TL;DR: You're expected to still use the bits as access/dirty flags, but instead of the hardware automagically setting them, you set them yourself from the page fault handler. (Or if you don't need to track those things, you just set the flags to 1 from the start.)
Re:RISC-V OS Using Rust: Memory Management Unit
by FullyFunctional on Monday November 04, 2019 @06:47PM
(#21448057)
> Just because we wrote 8 in the MMU mode, we don't quite have the MMU turned on. The reason is because we're in CPU mode #3, which is the machine mode. So, we need to switch to "supervisor"
I'd encourage him to start in Supervisor mode instead and use one of the standard bootloaders (bbl or openSBI) to deal with machine mode. This would be compatible with Linux and be more portable as different platforms will supply platform specific boot loaders.
Edit: original post I could’ve sworn was worded to imply it was what was what GP linked, but either I misread or it was edited, so changed my reply accordingly.
Re:RISC-V OS Using Rust: Memory Management Unit
by Taniwha on Monday November 04, 2019 @06:21PM
(#21447800)
Also missing from this tutorial - one really needs to execute a sfence.vma instruction after writing satp to sync CPU pipelines to new memory management state (otherwise code that happily runs on a simulator will fail on a real-world deeply pipelined CPU)
Re:RISC-V OS Using Rust: Memory Management Unit
by pavehawk2007 on Monday November 04, 2019 @06:52PM
(#21448092)
Patience, my friend. We're not quite there yet with this tutorial. We don't need sfence.vma for what I've covered here. Plus, there are about four ways to use the sfence.vma instruction (whether or not rs1 is zero or not and if rs2 is zero or not). I'd like to have some context behind each one of these four cases, but I can't do that in the OS's current state.
Re:RISC-V OS Using Rust: Memory Management Unit
by nautilus12 on Monday November 04, 2019 @10:32PM
(#21449362)
Can someone explain some soup to nuts applications that would benefiet greatly from this type of architecture? Why is RISC-V becoming so popular right now?
Re:RISC-V OS Using Rust: Memory Management Unit
by dreamcompiler on Monday November 04, 2019 @10:43PM
(#21449401)
RISC-V is popular because it's a clean RISC design (unlike IAxx) which is not controlled by any for-profit company (unlike Arm). That means anybody can use it, enhance it, or fix any not-yet-identified bugs in it without paying license fees.
Re:RISC-V OS Using Rust: Memory Management Unit
by nautilus12 on Tuesday November 05, 2019 @07:45AM
(#21451853)
Thanks, I gathered as much about RISCV, but my question was maybe more basic, kind of eli5 of why would someone would use RISC for an application over x86 or ARM, what level of task requires or benefits from a reduced instruction set chip. I noticed alot of video games have used it.
Re:RISC-V OS Using Rust: Memory Management Unit
by einpoklum on Tuesday November 05, 2019 @01:31PM
(#21455193)
If you're "using RISC", that means that you're producing something that involves a processor. If you're just making software you just need to have it compile with common compilers and have the relevant libraries available on your target platform (ok, I'm over-simplifying), so you don't "use processoer X over Y".
When you do use hardware, you're interested in things like power budget and price for comparable performance. RISC-V is now reaching competitiveness in some cases, and companies/people will now start choosing to use it on the merits. If, there is, there's an OS available and a bunch of supporting tools and libraries.
Re:RISC-V OS Using Rust: Memory Management Unit
by dreamcompiler on Tuesday November 05, 2019 @02:40PM
(#21455875)
If you're designing a new computer platform, do you care about power (i.e. does it need to run on batteries)? If so you probably want a RISC architecture rather than CISC (although the Intel Atom tries hard to be a low-power CISC machine). That leaves you with two choices: Arm (used in all smartphones, some Chromebooks, and Raspberry Pi) or RISC-V. Arm is more mature and there's a lot more software available, but it's not an open source architecture.
Re:RISC-V OS Using Rust: Memory Management Unit
by silasdb on Tuesday November 05, 2019 @06:23AM
(#21451366)
There are recently some guides about how to build an operating system in Rust. Rust is innovative and great, but also brings complex new ideas. Can it slow down learning and implementing because the developer have to dedicate too much time to the language itself?
Re:RISC-V OS Using Rust: Memory Management Unit
by mr__y on Tuesday November 05, 2019 @07:26AM
(#21451733)
I believe that building a full blown OS requires dedicating so much time that this overhead due to the language itself will not be significant. On the other hand, without the sufficient experience with the language itself, it's easy to run into problems that will consume a significant amount of time
Re:RISC-V OS Using Rust: Memory Management Unit
by Taniwha on Monday November 04, 2019 @04:49PM
(#21446882)
sigh - the PTE A&D bits cause traps they way they do so that software can implement them (if it needs them, and not if it doesn't), it's an old trick and very much a RISC thing - not wanting to burden the hardware with something that software can do
Re:RISC-V OS Using Rust: Memory Management Unit
by monocasa on Monday November 04, 2019 @06:55PM
(#21448122)
There's no reason to sigh, it is a pretty goofy thing to both specify the bits as separate from the permissions, and check them, but not fill them out.
Going through RISCS I've implemented MMU code for:
MIPS - Has what they call a Dirty bit, but no separate RO bit, the dirty bit is really the ~RO bit.
SH* - See MIPS (lol, that could be their tagline)
Sparc - Doesn't really specify an MMU, but the "Reference MMU" does specify that the Modified bit (AKA the Dirty bit) is filled in by the MMU
PowerPC - Referenced and Changed bits in the PTEs are updated by the MMU.
ARM - Doesn't specify any A&D like construct.
Am I missing any? I can't think of an arch off the top of my head that has separate A&D from RWX, and doesn't have the MMU fill them in for you. Well other than RISC-V, lol.
Re:RISC-V OS Using Rust: Memory Management Unit
by Taniwha on Monday November 04, 2019 @11:17PM
(#21449563)
Vax's had modified bits, 68030s had both (dirty managed in software), 80x896s have both [an 'unnamed' risc architecture (I worked on) had both, managed in software]
The big advantage of handling this stuff in software is that any hardware doing this has to go through the system caches which is just really messy - better to use the existing coherent paths already provided and provide hardware support so you don't have to do this often
Re:RISC-V OS Using Rust: Memory Management Unit
by Taniwha on Monday November 04, 2019 @06:02PM
(#21447629)
accessed and dirty (where a page has been accessed and whether it has been changed)
You need to know "dirty" to know whether a page needs to be written back to a swap file (or needs to be duplicated in lazy copying cases), you may want to know "accessed" if you want to do the accounting to push out less often used pages when memory gets short
If anyone's wondering, I explained the reason:
https://github.com/pavehawk2007/osblog/issues/11
TL;DR: You're expected to still use the bits as access/dirty flags, but instead of the hardware automagically setting them, you set them yourself from the page fault handler. (Or if you don't need to track those things, you just set the flags to 1 from the start.)
I'd encourage him to start in Supervisor mode instead and use one of the standard bootloaders (bbl or openSBI) to deal with machine mode. This would be compatible with Linux and be more portable as different platforms will supply platform specific boot loaders.
https://en.wikipedia.org/wiki/RISC_OS
http://osblog.stephenmarz.com/index.html
Edit: original post I could’ve sworn was worded to imply it was what was what GP linked, but either I misread or it was edited, so changed my reply accordingly.
When you do use hardware, you're interested in things like power budget and price for comparable performance. RISC-V is now reaching competitiveness in some cases, and companies/people will now start choosing to use it on the merits. If, there is, there's an OS available and a bunch of supporting tools and libraries.
Going through RISCS I've implemented MMU code for:
MIPS - Has what they call a Dirty bit, but no separate RO bit, the dirty bit is really the ~RO bit.
SH* - See MIPS (lol, that could be their tagline)
Sparc - Doesn't really specify an MMU, but the "Reference MMU" does specify that the Modified bit (AKA the Dirty bit) is filled in by the MMU
PowerPC - Referenced and Changed bits in the PTEs are updated by the MMU.
ARM - Doesn't specify any A&D like construct.
Am I missing any? I can't think of an arch off the top of my head that has separate A&D from RWX, and doesn't have the MMU fill them in for you. Well other than RISC-V, lol.
The big advantage of handling this stuff in software is that any hardware doing this has to go through the system caches which is just really messy - better to use the existing coherent paths already provided and provide hardware support so you don't have to do this often
You need to know "dirty" to know whether a page needs to be written back to a swap file (or needs to be duplicated in lazy copying cases), you may want to know "accessed" if you want to do the accounting to push out less often used pages when memory gets short
I like rust and more architectures are sorely needed, but this seems... Calculated