1. Messages
  2. Access unprivileged regions from OS

Re: Access unprivileged regions from OS

Andrew Waterman
 



On Fri, Oct 30, 2020 at 4:25 AM Andrea Mondelli <andrea.mondelli@...> wrote:



There is an alternative way to have the same behavior? I was thinking other examples like checking user parameters when syscall are called.

 

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 privilege with which S-mode loads and store access virtual memory cannot be used for specific addresses (i.e. check the function parameters of a syscall) avoiding the sstatus update overhead, right? 

 

According to the manual, “Operating systems can execute the majority of code with SUM clear; the few code segments that

should access user memory can temporarily set SUM.” the SUM must be temporary set and unset per syscall, then.


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 args are passed and returned in registers; and many syscalls that do access user memory do so in bulk, amortizing the cost of the sstatus writes across many memory accesses, cache misses, etc.)

 

Changes to the sstatus fields SUM take effect immediately, without the need to execute

an SFENCE.VMA instruction, so we cannot really consider this set/unset an overhead, probably.

 

Any (historical or practical) reason to avoid solutions like ad-hoc privileged instructions for this purpose?


At the time, we felt it was best to conserve opcode space and keep the ISA simpler.

(For somewhat different reasons, the hypervisor extension has chosen to add new instructions for accessing guest OS memory.)
Join {tech-privileged@lists.riscv.org to automatically receive all group messages.