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

+1

Hi all, Andy and I would like to propose the following charter for the CMO TG for approval: The Cache Maintenance Operation, or CMO, task group intends to define data cache maintenance operations for

I'll leave the wording decision up to John Hauser.

OK, that makes sense. I think that this minor change would be clearer (and I can make a PR if you agree): "HLVX cannot override machine-level physical memory protection (PMP), so attempting to read

It means what it says. Execute-only PMP regions (or PMA regions, for that matter) cause HLVX to raise an exception. This is consistent with how mstatus.MXR is defined. (The implication is that code

HLVX requires execute permission "during address translation" and explicitly requires PMP read access. Since PMP is not address translation, does HLVX require PMP execute permission in addition to

The 16-PMP scheme is the only ratified one. It's highly unlikely, but the CSRs allocated to the 64-PMP scheme might not ultimately be so purposed. The most conservative option is to stick to the

Hello, Sorry about reviving an old post but I would like to verify as I do not find this clear in the privileged draft. If a decision is taken to implement exactly 16 PMP registers, should accesses to

Paul Donahue wrote: It seems the algorithm in section 4.3.2 was edited since section 5.5.1 was written. I'm looking at updating section 5.5.1 to adapt to the changes. - John H.

I think that there are a few problems in section 5.5.1 of the hypervisor spec. It says that G-stage translation follows the same algorithm as section 4.3.2 with a few changes. However: 1. the first

Hi Yifei, Both full emulated I/O devices (e.g. UART, RTC, PCIe devices, etc) and paravirtual I/O devices (e.g. VirtIO devices, XenPV devices etc) have MMIO registers which are trap-n-emulated by

i remember using DEC VAX ancillary control processes and writing knob and trackball device drivers in user land in the early 80s. I tried to find something describing this but I think it is lost to

Hi Anup, Sorry for the confusing description of the background in this proposal. To be clear, we here divide the implementation of trap-and-emulated I/O devices into full emulated I/O devices and

Hi John, Yes, we believe that the new interrupt architecture and an IOMMU, which is regarded as a pass-through method as we knew, can indeed minimize the number of times of GuestOS exiting. However,

Hi, Thanks for your comment. To solve the security problem about the URET instruction, we further add a field, called HUR, in hstatus to control the behavior of URET instruction. When the