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"

Good question. A couple of quick thoughts: - D-mode is not a required part of the Debug spec, i.e. a fully compliant implementation of the full Debug spec may not use an "execution-based" approach

By Greg Favor · #473 ·

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

Another thought from one of my debug coworkers: what do we want to do about debug (D-mode)? Having a bit that says "inhibit counting when we are in D-mode" would allow debuggers to do accurate perfmon

By Brian Grayson · #472 ·

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

Dang. I think that typo crept in at the last second. The bit numbering for the bottom three bits should be 58, 57, and 56 - resulting in the full top byte of mhpmevent being covered. Thanks, Greg

By Greg Favor · #471 ·

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

I noticed another typo that I don't think has been pointed out -- reuse of bit 59. bit [59] VSINH - If set, then counting of events in VS-mode is inhibited bit [59] VUINH - If set,

By Brian Grayson · #470 ·

Re: Preferred manner of supporting bus errors in RISC-V

Hello, Thanks for raising this Arjan, it's been a low-priority item on my TODO list to open a discussion on bus errors for a while now (I work on Ibex amongst other things at lowRISC). I think RISC-V

By Greg Chadwick · #469 ·

Preferred manner of supporting bus errors in RISC-V

Hi all, We want to add support for ‘bus errors’ in our RISC-V design (e.g. signaled via AXI bresp/rresp signals). I studied a couple of different RISC-V architectures and I do not see a common

By Arjan Bink · #468 ·

Re: RISC-V H-extension freeze consideration

I generally agree with Andrew. At the same time I'll also observe that, practically speaking, the AIA is coming soon and it very much directly interacts with the H extension. So waiting a little

By Greg Favor · #467 ·

Re: RISC-V H-extension freeze consideration

In other architectures, those devices are needlessly complex in part because they weren’t co-designed with the ISA. Yes, they can be independently designed, but possibly with regrettable

By andrew@... · #466 ·

Re: RISC-V H-extension freeze consideration

On all major architectures (x86 and ARM64), the virtualization-aware interrupt controllers and IOMMUs are totally independent from ISA virtualization support. We already the required ISA support

By Anup Patel · #465 ·

Re: RISC-V H-extension freeze consideration

* substantially greater utility Shouldn’t write emails on phone...

By andrew@... · #464 ·

Re: RISC-V H-extension freeze consideration

I’m not in support of freezing it yet. My concern is that development of virtualization-aware interrupt controllers and IOMMUs will lead to reconsideration of some of the details. All of these items

By andrew@... · #463 ·

RISC-V H-extension freeze consideration

Hi All, The RISC-V H-extension v0.6.1 draft was released almost a year back in May 2020. There has been no changes in the H-extension specification since then. Meanwhile, we have RISC-V H-extension

By Anup Patel · #462 ·

Re: [RISC-V] [tech-unixplatformspec] [RISC-V] [tech-privileged] [Announcement] Successful KVM RISC-V bring up on FPGA (Rocket core with H extension)

Sure. I will send that once I have the detailed instructions available in public domain. -- Regards, Atish

By atishp@... · #461 ·

Re: [Announcement] Successful KVM RISC-V bring up on FPGA (Rocket core with H extension)

congrats! can we send something out to tech-announce about it? -------- sent from a mobile device. please forgive any typos.

By mark · #460 ·

Re: [Announcement] Successful KVM RISC-V bring up on FPGA (Rocket core with H extension)

Awesome!

By andrew@... · #459 ·

[Announcement] Successful KVM RISC-V bring up on FPGA (Rocket core with H extension)

Hi, We are glad to announce that we are able to boot Linux in KVM guest on a FPGA (Rocket chip + H extension v0.6.1). We now have three hypervisors working on a Hardware with H extension. 1. KVM

By atishp@... · #458 ·

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

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

By Greg Favor · #457 ·

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

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

By Brian Grayson · #456 ·

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

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

By Greg Favor · #455 ·

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 ·

861 - 880 of 1333

Home Hashtags Subgroups Terms