Using 'hpm' probably would be a bit confusing. But I'll look into alternatives. Btw, since a new extension naming standard is being developed, ultimately this (and all other extensions) will need to

Given the discussions about cache-ops and the name for them on tech-cmo and the desire to avoid "co", "COF" (which can also mean "change of flow") may not be the best choice for the extension

You're correct. Standard mideleg functionality applies. I'll incorporate a clarification note. As you note, this starts getting into adding a number of bits and associated functionality. The

Could you clarify how this extension interacts with mideleg? I assume interrupt 13 would be taken in M-mode by default unless it is delegated to S-mode, but it would be nice to state this

One typo crept by me and some other pre-reviewers: scountovf contains shadow copies of the OF bits in the 29 mhpmevent CSRs (i.e. mhpmevent3-mhpmevent31). Greg

Hi all, Recently the TSC established a lightweight "fast track" architecture extension process that small, straightforward, relatively uncontentious arch extension proposals can utilize. This is the

Hi Anup, If I understand correctly, this proposal will not cause the problem of your 2nd point because not all the MMIO will trap to user space in this proposal. The proposal still allow MMIO traps

as suggested by phil attached is a proposal for SV57K this was initially posted to the privileged tech_privileged group http://bsc.es/disclaimer

This probably should be discussed on the tech-virt-mem list. Cheers, Phil

not really if necessary we can define 2 64_bit registers. i wanted to simply define what machine state is needed that is a good catch thank you WARNING / LEGAL TEXT: This message is intended only

Your SATPU and SATPK registers seem to each contain: 64-bits of PPN, 32-bits of ASID, 4-bits for MODE and 28-bits reserved. But that adds up to 128-bits which is double the size of CSRs on 64-bit

attached is a proposal for the definition of RV57K. RV57K is an extension to RV57. the main extension is to incorporate two HARDWARE registers. These registers are used to partition user and

Exactly. - I was just pointing out that this is a little different than the usual handler, but still needs to do the same saving - just a bit or non-normative text.. And you need to save scratch as

This is no more a problem for RNMI than anything else. The S mode handler must save (push) scause/sepc before doing anything that could cause an exception. Then it can handle nested exceptions.

I suppose it depends on the exact design of the watchdog timer. In the scheme I'm familiar with, an NMI arrives every few seconds regardless of the state of the system. Then the interrupt handler is

If you're not (or can't) resume the interrupted process - it's fatal. No forward progress is fatal, and I would classify watchdog timer interrupts as fatal. The performance monitoring example is not.

One case where NMIs are used on x86 for non-fatal conditions is for performance monitoring. If an operating system wants to accurately measure its own performance, then ideally it should be able to

My concern is that if an RNMI occurs during an exception handler, and the RNMI handler encounters an exception, the exception return point. cause, and prev. priv state is lost - that's fatal. It's

Thank you for pointing out that there are two RNMI vectors: one for NMI and one for exceptions. As you surmised, I missed that but I think that addresses my concern. -Paul

1) Is anyone using non maskable interrupt for anything other than fatal conditions? a) if so,why not just increase the range of interrupt priority levels, relocate the maskable interrupt priority