let's create a top sheet and add this please. philipp is working on a review proposal. likely more like tech-announce for 2 weeks and notify TSC and the board. etc Get BlueMail for Android

Hi All, The KVM RISC-V AIA support has been successfully validated with AIA IMSIC virtualization features emulated by QEMU RISC-V. This means KVM RISC-V Guest Linux works perfectly fine with Guest VCP

In a system using SV-39, RISC-V privileged spec defines the behavior of address calculation and page fault detection: Instruction fetch addresses and load and store effective addresses, which are 64 b

Table 3.7 of the privileged spec lists the synchronous exception priorities. The hypervisor chapter adds guest page faults and virtual instruction exceptions but I don't see where it states how they a

Following on to https://github.com/riscv/riscv-isa-manual/pull/701. There should be more said that there's no expectation of implementations "edge detecting" the "becomes pending" event. For example,

mepc, as an example, has this: """ mepc is a WARL register that must be able to hold all valid virtual addresses. It need not be capable of holding all possible invalid addresses. Implementations may

Extrapolating from the discussion on Smepmp discovery, it is reaonable to expect that in the future any security feature will potentially run into the same issue, that is, any data structure is not tr

Hello all, When we initially defined mseccfg as part of Smepmp we specified that the existence of that CSR would also mean that ePMP (at least MML and MMWP) is implemented. Obviously since other secur

Resending from correct email address Begin forwarded message: From: krste@... Subject: Re: [RISC-V] [tech-privileged] RISC-V H-extension freeze consideration Date: August 1, 2021 at 1:41:10 PM PDT To:

It’s a cheap, effective solution. But I think Andrew’s question is whether a solution is needed. If the early boot code knows what hardware it’s running on, it doesn’t need the information. But will t

Section 25.7 of the unprivileged spec says that standard supervisor-level ISA extensions are named using S as a prefix. Section 25.9 says that standard machine-level ISA extensions are named using Zxm

I'm unclear whether you are objecting to 4 byte alignment, or reserving the low bits for something else in the future. In any case, I am not seeing why 4 byte alignment should cause any issue even wit

Greg wrote: You are correct. An editing error, of course. I'm aware of at least one other mistake. Under "Motivation" it currently says: Actually, only some of the AIA's supervisor-level CSRs need swa

John, See below for a couple of small but important typos. Greg The references to bits 57 and 58 in the following two paragraphs are incorrect and should be to bits 58 and 59.

Josh Scheid wrote: For that very reason, we don't intend to allow such extensions to be enabled by a stateen bit. The dual-use case can apply only for extensions that don't have this issue, like Zfinx

This works for pure state enables, but may have issues for extensions that use the field for more than that (the allowed use for, say, the dual-purpose cases above). Particularly if the extension is o

Forwarding to tech-privileged so the hypervisor folks can weigh in...

Hello Greg, Στις 2021-06-28 22:29, Greg Favor έγραψε: Have you considered using mscratch for this instead of defining a new CSR ? Regards, Nick

Folks, I have below the latest version of the plan to add optional "stateen" (State Enable) CSRs to the RISC-V Privileged Architecture, now in the form of a fast-track extension proposal. Much of this

Why does it need to be a CSR? In other parts of the boot flow the device tree pointer is passed via a normal general purpose register. Why can't the same be done here? Jonathan