The Hypervisor extension adds bits to some of the existing M-mode CSR's. When this extension is not implemented, these bits are hardwired to zero. When the extension _is_ implemented these bits become

Hi Andrew, all, The current priv spec reserves lower 2bits of mtvec (ad stvec) to indicate vectored interrupts, there’s an issue that if exception handler is word aligned but SW mis-program the lower

Dear team, This may be a basic question: I am trying to figure out where in the physical memory map are the "mtime" and "mtimecmp" registers to be placed. Per the privileged spec, these registers are

Hi all, I have a simple question: does the architecture allow table walk accesses (reads or writes) to regions with the non-idempotent PMA? The architecture doesn't explicitly disallow it, so the answ

Paolo Bonzini wrote: Okay, I get it now. You're proposing we bring back hstatus.VTW, the HS-mode analog to mstatus.TW. (We had the VTW bit originally in hstatus, but dropped it long ago.) Anyone else

Hi, Reading through the hypervisor extension v0.6, I noticed the new register called hvip. The spec says that this register is intended for the hypervisor to write to indicate pending interrupts for t

Dear Privspec members, You may recall that I had argued for an operation to flush microarchitectural state in order to allow the OS to prevent timing channels. I believe the need for this was not disp

Hello tech-privileged guys, I've created a pull request for the RISC-V privileged spec in response to requests from our hypervisor software authors: https://github.com/riscv/riscv-isa-manual/pull/518

Hi All, We have updated QEMU RISC-V, KVM RISC-V and Xvisor RISC-V for RISC-V H-Extension v0.6 spec. The QEMU repo with RISC-V H-Extension v0.6 support can be found here: https://github.com/kvm-riscv/q

The mtime and mtimecmp registers are defined as 64-bit memory-mapped registers. The priv spec says that - in RV32 - mtimecmp can be written as a pair of 32-bit registers. Since this was made specific

When one of the new HLV/HSV instructions faults, what virtualization and privilege modes are recorded in mstatus.mpp/mpv, or in sstatus.spp/spv and hstatus.spvp? Are they based on the actual modes fro

A clarification is required in RISC-V H-Extension spec regarding scope of HSTATUS.VTVM bit. Currently as-per the spec, all virtual memory management instructions (both SFENCEs and HFENCEs) will trap t

Hi Gernot and Yanyan, It's been a couple of months since you first sent (Dec. 4) your document reporting your experience adapting the seL4 microkernel to draft 0.4 of the RISC-V hypervisor extension,

Nick Kossifidis wrote: All of the other proposals, including the one you favor, have this exact same property when MML = 0. As I wrote in my document, and have tried repeatedly to make clear, the sett

Στις 2020-02-28 21:14, John Hauser έγραψε: You've excluded the possibility of having a region that's writeable by S/U and executable by M mode at the same time. However it's possible for S/U to put co

Hi everyone, We have spent a considerable amount of time reviewing the different proposals and have come to some conclusions. 1. The PMP enhancement proposal can meet our needs with the following modi

Ø why don't you instead simply not program any lock bits until you get to the point that you would have changed DPL from 1->0? Because we can’t program the permissions we need without locking the entr

Hi Allen, The point I was trying to make about locked PMP entries, but failed to communicate before, is this: When a system starts up after reset, PMP is enforced according to a certain set of rules.

Hi Nick, John, Here's my proposal for adding two fields to the proposed MSECCFG CSR: DPL and DMC. This proposal assumes that the programming model for the permissions is sufficient without adding anot

Creating a new thread, for a new topic, although I'm excerpting some old email as inspiration. Anyway: Andrew Waterman tells me that 1 of the big purposes of M-mode is to emulate instructions. For exa