tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Re: Fast-track extension proposal for "Hardware Performance Monitor count overflow and mode-based event filtering"

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

By Phil McCoy · #454 ·

Re: Fast-track extension proposal for "Hardware Performance Monitor count overflow and mode-based event filtering"

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

By Greg Favor · #453 ·

Fast-track extension proposal for "Hardware Performance Monitor count overflow and mode-based event filtering"

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

By Greg Favor · #452 ·

Re: Proposal: Delegating Exceptions from VS-mode or VU-mode to U-mode

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

By 陈家浩 · #451 ·

Re: rv57k virtual address space

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

By swallach · #450 ·

Re: rv57k virtual address space

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

By Phil McCoy · #449 ·

Re: rv57k virtual address space

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

By swallach · #448 ·

Re: rv57k virtual address space

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

By Jonathan Behrens <behrensj@...> · #447 ·

rv57k virtual address space

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

By swallach · #446 ·

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

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

By Allen Baum · #445 ·

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

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.

By Paul Donahue · #444 ·

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

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

By Jonathan Behrens <behrensj@...> · #443 ·

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

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.

By Allen Baum · #442 ·

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

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

By Jonathan Behrens <behrensj@...> · #441 ·

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

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

By Allen Baum · #440 ·

Re: Resumable NMI proposal

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

By Paul Donahue · #439 ·

Re: Resumable NMI proposal

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

By Richard Trauben · #438 ·

Re: Resumable NMI proposal

1. I think some of the questions and discussion concerning this proposal have arisen because the proposal is a little too terse. It would be helpful to have more about the specific use cases that the

By John Hauser · #437 ·

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

Shouldn't exceptions during an NMI just jump to the normal exception handler? That seems like the simplest solution, and would be the behaviour if this extension didn't specify something

By Jonathan Behrens <behrensj@...> · #436 ·

Re: [RISC-V] [tech-fast-int] [RISC-V] [tech-privileged] Resumable NMI proposal

The problem is that, although RNMI has a separate vector, the RNMI vector can handle both NMI and normal exceptions but the cause information is only updated on NMI. Here's an illustration of my

By Paul Donahue · #435 ·

881 - 900 of 1334

Home Hashtags Subgroups Terms