You say "The value that a CSR instruction reads from mip into the instruction'srd destination is not affected by which CSR instruction does the read, whether it's CSRR, CSRRW, CSRRC, or CSRRS. " but

Simon Davidmann wrote: The section you are quoting, 3.1.9, "Machine Interrupt Registers (mip and mie)", says nothing about the N extension. If you look at the figures for the mip register in that

Ken Dockser wrote a document on instruction encoding guidelines, but not the actual values of the minor/major opcodes, or sub-minor (functX) fields. Attached

Krste has said (correct me if I am wrong) that the unpriv SC owns the opcode space. I know there is a lot of overlap in the SC members but I suggest we get that SC officially in the loop. I have CC'ed

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

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

One could argue that the current spec and the sentence in question (with or without the suggested modification), is clear in calling out when an sfence.vma is not required. But I agree that adding a

Do you want to add more detail about the page-based virtual memory being disabled case? (that some implementations may require sfence.vma, depending on whether they do XXX with their TLB)? That

In section 3.6.2 of the Privileged spec discussing changing PMP settings, it currently says: I would like to suggest removing "or when it is disabled" and just say: The motivation is that

RISC V needs CMOs, and hence a CMO Working Group EditNew Page

I'd also strongly argue for there only being a single configuration for both virtualized and non-virtualized systems. The fewer different cases that software has to handle, the better for everyone.

Hi Alan, My statement “Allowing S-mode to write HPMCOUNTER CSR is good but won’t benefit much.” is because: Linux PMU updates counter value in-frequently only in start() callback The

Hi Anup, > The “bypass-sbi” DT property will break QEMU virt machine No, it won’t. Why should QEMU virt machine’s PMU follow this flag? The platform can totally choose not to support

The “bypass-sbi” DT property will break QEMU virt machine for KVM because same QEMU virt machine is used with both TCG and KVM acceleration. This is yet another work-around for doing things

> I think I am repeating myself here but still don’t see any benefit of allowing HPMCOUNTER CSR write access to S-mode. On the contrary, it will make context switching expensive for hypervisors. I

Yes, there is no way for kernel to know whether it is running in HS-mode or VS-mode. We would like to keep it that way. Regards, Anup From: tech-privileged@... <tech-privileged@...>On Behalf

Hi Alan, I think I am repeating myself here but still don’t see any benefit of allowing HPMCOUNTER CSR write access to S-mode. On the contrary, it will make context switching expensive for

I may be dense (I won't take a poll on that though), but if a kernel can detect that it is in S-mode vs. VSMode, that sounds like a buggy virtualization scheme. The kernel should (appear to) be in

Hi Anup, > Linux PMU driver framework only updates counter value in “add()” or “start()” callback. That’s why allow S-mode write HPMCOUNTER CSRs won’t provide much benefit. It doesn't

HI Alan, I never said HPM overflow interrupt is not important. The MHPMOVERFLOW CSR proposed by Greg is perfectly fine. I think you missed my point regarding H-extension. If S-mode is allowed