In RISC-V, instruction fetch addresses and load and store effective addresses are XLEN bits wide; however, an implementation can have a smaller physical address size. When a core is in M-mode or Bare

I think the fact that the current platform spec draft lacks any way for S-mode to toggle misa.H, for S-mode to request a specific value, or even a way for configuring M-mode to set/unset misa.H at

Without a doubt, there’s value in building machines that can faithfully emulate less-capable machines. With that in mind, writable misa.H is a well architected feature. Whether it rises to the level

Disabling FP and Vector units (or any extension that adds a lot of user-privileged stage) can be useful for lazy context switching, but that should be done via mstatus.FS/XS rather than misa bits.

I don't disagree. Which begs the question of whether there should be any encouragement or expectation that any implementations (barring inevitable exception cases) of misa should have writable bits.

Thanks Andrew and Gregg. I'll ask the question on unixplatformspec. Cheers, Phil

My own (possibly unpopular) take is that implementing writable misa.H is a mess, and the benefits don’t come close to justifying the effort.

Phil, Yes, this would be a good question for the platforms (not profiles) group to discuss . I'll go ahead and raise it to the group. The H extension does explicitly "encourage" implementations to

I recommend visiting the tech-unixplatformspec mailing list. The profile and platform specs are far from being frozen, and so your input may well be impactful.

Hi, Does anyone know why the RV22A profile draft (https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc) mandates the following: misa If the H extension is supported

Paul Donahue wrote: You have the effect of "HS-qualified" backwards. An instruction raises a virtual instruction exception _only if_ it is HS-qualified. If it isn't HS-qualified, then it must raise

I invite comment on this proposed update to the rules for raising virtual instruction exceptions when in VU mode: https://github.com/riscv/riscv-isa-manual/pull/730 - John Hauser

Paul Donahue wrote: From the hypervisor extension chapter, Section 5.2, "Hypervisor and Virtual Supervisor CSRs": Some standard supervisor CSRs (scounteren and scontext, possibly others) have

Explicitly cc'ing John on this H extension oriented question.

scounteren's effect on VU-mode is unclear. VU-mode accesses to HPMn do not necessarily have "insufficient privilege" since hpmcountern is listed in table 2.2 as requiring user privilege. Is

Yes, that's the consensus of the RISC-V LLVM/GNU community :)

Yes, that was the plan, Krste | On Thu, Aug 26, 2021 at 8:31 PM Kito Cheng <kito.cheng@...> wrote: | For non-priverage extension, toolchain can control version for each | extension by

Should I assume that for the ratified vector spec simply 'v' can be specified? And that a version number is only needed to refer to a pre-ratified version of the vector spec? Greg

it sounds like we are aligned Get BlueMail for Android On Aug 26, 2021, at 8:27 PM, Kito Cheng <kito.cheng@...> wrote:

let's create a top sheet and add this please. philipp is working on a review proposal. likely more like tech-announce for 2 weeks and notify TSC and the board. etc Get BlueMail for Android On Aug 26,