It works fine, but it's not as nice as the system itself slowing down to your debugging speed. (Although slowing the system down will generally be imperfect in any case, because systems have other

Are there downsides to the debugger inhibiting the timer interrupt by setting STIE to 0? This seems like would provide similar benefit even for a multi-hart system... regards ved

stoptime is nice on single-hart systems, but not really practical in multi-hart systems where one hart can be running while another is halted. The main benefit is that it allows you to single step

Hi Ved, Are we ready to finalize the changes after all the comments and discussions on the list of questions you had on this thread? If yes, can you send a PR for these changes please? I see the PCIe

This is platform specific address and it will break for platforms having MTIME register at some other address. Such optimizations, increasingly make a SBI implementation platform specific. This is

RISC-V SBI provides platform agnostic functions for kernels. The nomal handling procedure in an SBI implementation would include context switch and call higher language code, e.g. Rust or C code.

I agree that the stoptime=1 requirement should be removed. I can think of a case where stoptime might be useful but it would be a contrived example that's not useful in the real world. I should have

Btw, that would be a DRET to exit Debug mode (not an MRET). Greg

I'm cc'ing Tim Newsome and Paul Donahue (chairs of the Debug TG). Tim or Paul can comment on the debug value in sometimes being able to stop the local hart time CSR from advancing while in Debug

Just fwiw, most multi-hart RV implementations have a shared MTIME register. (CLINT, for example, reflects this.) I'll resend the original question to both chairs of the Debug TG so they can comment

Greg HI I agree architecturally there is just memory-mapped MTIME. We can leave it at that. What I meant by clock was where a each hart has its unique memory mapped MTIME and thereby is clocked by a

Architecturally there is just the memory-mapped MTIME register and the time CSRs - where time is a (delayed) copy of MTIME. How MTIME values get into the time CSRs is implementation-specific (with

So there is an assumption here that somehow time is broadcast and not the clock. For an implementation that does clock broadcast this requirement requires having a shadow time that counts while

And also re-sync'ing when coming out of deeper power management sleep states. The mechanism for software reading mtime is memory-mapped register reads; ditto for trap-and-emulate of hardware reads of

What you describe sounds very implementation dependent; I had always imagined that mtime would not be broadcast, but an mtime count enable bit would be, to keep the local copy synched. That has its

<ksankaran@...> wrote: Not sure why these are not rendered correctly in gmail. The deleted text seems to be garbage as well which indicates a rendering issue in gmail. Please make sure

I'm cc'ing Paul Donahue (vice-chair of the Debug TG). He was involved with distilling out of the enormous amount of optionality in the Debug spec, what would be suitable to require in OS-A platforms.

Thanks, I definitely misunderstood the intent. So the expectation is that, in Debug Mode, reads to mtime will see time continue to progress, but reads to the time CSR will see a frozen value. Reads

Oops, it has been a while since I've read this spec. I withdraw my comment, if it's indeed the case that shared implementations of mtime need not be affected by stoptime.

I think there's a little bit of confusion going on. The 'stoptime' bit is defined as "Don’t increment any hart-local timers while inDebug Mode." I take this to clearly not be referring to MTIME,