I would like to get people's views on the question of when is an sfence.vma required after changing the satp.mode field (to see what support there is for the following change/clarification in the Priv

Hi All, We now have a simple Nested MMU (i.e. Two-stage MMU) test-suite available as part of Xvisor white-box testing framework. This test-suite runs in HS-mode and does nested MMU testing using the H

Hi All, We have updated Spike, QEMU RISC-V, KVM RISC-V and Xvisor RISC-V for RISC-V H-Extension v0.6.1 spec. The QEMU RISC-V is our default development vehicle for RISC-V hypervisor software (because

The satp register has reserved values. Some implementers will, no doubt, want to define non-standard behavior based on satp. I would like to propose that we define some of the reserved values in satp

Hello Everyone, We have come up with some ideas about improving the performance of virtual machines on the RISC-V architecture. Here’s the first piece which proposes a dedicated clock source and a clo

Thanks for the timely comment, we are aware of the htimedelta CSR in the hypervisor spec. Section 3 is meant to propose aliases available in VS-mode and VU-mode. Because they are meant to provide time

Yeah, my point is that the current definition of htimedelta already says what you want it to say about the time CSR. Reading the time CSR in VS-mode or VU-mode isn't required to trap, and it returns t

I see. This is new information for me though. The ‘that is’ in the current spec makes the sentence look like an reiteration of the functionality of the htimedelta itself. I totally didn’t expect this

hcounteren.TM is already defined this way, for exactly this purpose.

The QEMU “virt” machine emulates both TIME CSR and HTIMEDELTA CSR so no trapping happens when accessing TIME and HTIMEDELTA CSRs from VS/VU mode on QEMU. Although, QEMU “sifive_u” machine does not emu

In that case, yeah, section 3 does not propose anything new. 发件人: Andrew Waterman [mailto:andrew@...] 发送时间: 2020年8月4日 16:40 收件人: zhaosiqi (A) <zhaosiqi3@...> 抄送: tech-privileged@... 主题: Re: [RISC-V] [

Thanks for the clarification. It turns out that I was looking at an older code base. 发件人: Anup Patel [mailto:Anup.Patel@...] 发送时间: 2020年8月4日 16:48 收件人: zhaosiqi (A) <zhaosiqi3@...>; Andrew Waterman <a

It's good news we came to the same conclusions independently :)

Yeah, sure. : ) 发件人: Andrew Waterman [mailto:andrew@...] 发送时间: 2020年8月4日 16:58 收件人: zhaosiqi (A) <zhaosiqi3@...> 抄送: Anup Patel <Anup.Patel@...>; tech-privileged@... 主题: Re: [RISC-V] [tech-privileged]

Hello, Background: You may be aware that the RISC-V Debug Specification 0.13 defines two CSRs, mcontext and scontext, that can be used to qualify hardware breakpoints in a particular OS process or thr

P extension specification has defined a fixed-point saturation flag CSR. We need to allocate it officially in the user standard read/write address range. Should we use the same CSR for V and P extensi

RISC V needs CMOs, and hence a CMO Working Group EditNew Page All successful computer instruction sets have Cache Management Operations (CMOs). Several RISC-V systems have already defined implementati

P extension instructions need to allocate opcode encoding space officially in the OP opcode space or other major opcode (such as reserved opcode). What is the best way to decide on this and officially

We posted this on https://groups.google.com/a/groups.riscv.org/g/isa-dev/ but had no response in 2 weeks - so maybe this is a better place: Looking forward to a response. Simon The Privileged Architec

In section 3.6.2 of the Privileged spec discussing changing PMP settings, it currently says: "If page-based virtual memory is not implemented, or when it is disabled, memory accesses check the PMP set