the current size of the virtual address space is 48 bits. (per the june 2019 spec - volume II) as many of you know, INTEL has increased their address space to 57 bits. several designers of server

The actual PTE access is either a page-table data read or page-tabledata write (which gets checked against PMAs and PMPs as such). But the "original access type" refers to the access that is being

From the Privileged spec, the 2nd step of virtual Address Translation process said, [2. Let pte be the value of the PTE at address a+va.vpn[i]×PTESIZE. (For Sv32, PTESIZE=4.) If accessing pte

The sPMP proposal has not been discussed in any detail as far as I know, so it is hard to pin down. The advantage of sPMP is that it should be much lower cost and simpler compared to page-based

This is just a quick FYI. (Sorry if this is a bit spam'y; there isn't a clear TG to target with this email. And I don't expect that this is something that plays into any near-term RISC-V

Is sPMP an alternative to page-based permissions? If so, what advantage does it provide over the latter? Thanks, Freddie From: Andrew Waterman [mailto:andrew@...] Sent: Friday, October 30,

I'd tend to think that the user processes running under sPMP will have few enough data regions that software base-and-bounds checks on syscall arguments isn't prohibitively expensive.

That might mean that the sPMP being considered might need a probe of some sort. Bill On 10/30/20 3:39 PM, Jonathan Behrens wrote:

On 10/30/20 3:25 PM, Andrew Waterman wrote: Yes, I overstated a bit. But embedded address maps vary quite a bit more than Linux address maps. I have wondered whether we'd want a state bit, maybe in

In the worst case, a software page table walk isn't that expensive.

It's not especially Linux-centric; it's more conventional-OS-with-paging-centric. mstatus.MPRV handles the situation adequately for PMP-based protection in M/U systems. S-mode with general address

On 10/30/20 2:32 PM, Andrew Waterman wrote: That's, of course, a very Linux centric answer. With more general address maps - or a "bare MMU" - the problem is harder to solve. Do you have an

My experience has been that, in the grand scheme of the cost of the syscall, the sstatus writes don't have a major effect on performance. (Also, many syscalls don't need to access user memory, since

Right. SUM can be used to solve the same problem as LDTR/STTR, but it is not equivalent. To avoid the concern you describe, the Linux kernel first performs a bounds check to guarantee the address is

Hi Andrew, I’m not sure the sstatus.SUM bit is providing the equivalent of LDTR/STTR. The pair of load/store instructions lower their privilege level so that if they end up access privileged

Yeah. Set the sstatus.SUM bit, then use regular load and store instructions to access user memory, then clear sstatus.SUM. Thanks Andrew, I’d forgotten about SUM bit! But. It means the

Yeah. Set the sstatus.SUM bit, then use regular load and store instructions to access user memory, then clear sstatus.SUM.

Hi all, quoting the arm manual, "sometimes the OS does need to access unprivileged regions, for example, to write to a buffer owned by an application. To support this, the instruction set provides the

mcounteren is WARL. An editing error introduced this confusion earlier this year: https://github.com/riscv/riscv-isa-manual/commit/b3d494c7b2ef23dc57225eacd0ac0c165dfa1ddb -- which I'll fix now.

What is the architectural intention for a bit in 'mcounteren' that corresponds to an unsupported hpmcounter (i.e. the hpmcounter register is hardwired to zero)? Can or should this counteren bit also