On Jul 4, 2021, at 3:42 AM, Anders Magnusson <ragge%tethuvudet.se@localhost> wrote:
Agreed. No reason to make a 64-bit VM system in any way be similar to the old one.
Better to make it match the requirements of today. The Alpha VM might be a good one to look at, yes.
You will want something like FOE (fault-on-execute) so that you can support “W^X". Actually, if you implement the VM machinery with separate I- and D- TLBs, then it might be easiest to simply have a separate “valid” bit (PG_IV) to indicate a PTE is valid for the ITLB, and rename PG_V to PG_DV and have it mean valid for DTLB. In 32-bit mode, just wire PG_DV to PG_IV internally before the TLB selection logic and have it work as it does today.
I think it’s reasonable to forego mod/ref entirely in 64-bit mode. The software interfaces we have in the kernel today make it not very expensive to emulate, and it would likely save a fair amount of FPGA space to leave it out.
One thing you could decide to do is to have separate hardware pointers for the kernel-mode table vs the user-mode table, which like how the VAX works now of course (with the SBR vs the P0 / P1 BRs). That would simplify things a little at the software level (because there would be no need to update all of the user tables whenever an additional kernel page table is added; see the Alpha pmap_growkernel()). The downside of this is that you would always use exactly one more (I assume 8K) page of memory because the kernel level-1 table would be a separate page, so it’s maybe not worth doing since the software complexity of just having a single PTBR isn’t that huge (and adding kernel level-2 tables isn’t a very frequent occurrence… although I should instrument it in the Alpha pmap just for kicks…)
:-) I tend to really agree with you here. Also, since all other instructions work this way, marginally extra hardware would be needed.
That would be three instructions, like:
CASBI mb,rb,rb
CASWI mw,rw,rw
CASLI ml,rl,rl
Don’t forget CASQI in 64-bit mode :-)