tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

I think the solution is even simpler. Even if MTVEC[1] had not been used, data dependent traps are prohibited in Risc-V (that might be too strong a word; I don't know that its explicited prohibited,

By Allen Baum · #174 ·

Re: mtvec question

I think this is one of dozens of little mistakes you can make in bare-metal RISC-V programming, and adding an sstatus bit for it is IMO not a great allocation of resources. Hopefully you are

By andrew@... · #173 ·

Re: mtvec question

Lol Do you feel it is worth to add a bit in sstatus to restrict csrw stvec to 1) mask bit1~0; 2) fire an exception when writing non-0 value to bit1~0? A separate elf section can work in some

By Joe Xie · #172 ·

Re: mtvec question

It's already used: https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc#44-new-xtvec-csr-mode-for-clic

By andrew@... · #171 ·

Re: mtvec question

Are we going to use bit1 soon in the future? We are wondering if we can use bit1 to indicate there’s illegal value (WLRL) – if bit1 is written with 1 then fire exception. From:

By Joe Xie · #170 ·

Re: mtvec question

I have been bitten by this, too, but I have little in the way of advice. There are various software approaches to reduce the likelihood of encountering this problem, even if the programmer forgets to

By andrew@... · #169 ·

mtvec question

Hi Andrew, all, The current priv spec reserves lower 2bits of mtvec (ad stvec) to indicate vectored interrupts, there’s an issue that if exception handler is word aligned but SW mis-program the

By Joe Xie · #168 ·

Re: xTVAL Compliance restriction proposal

Thanks for your input, as always. I agree that, if we ultimately agree to tighten the behavior here, we need to specify the behavior for both HW and SW writes.

By andrew@... · #167 ·

Re: xTVAL Compliance restriction proposal

That sounds good. It would be great to see this software write behavior added to the Priv spec (along with whatever hardware write behavior that Allen's polling concludes with). Thanks, Greg

By Greg Favor · #166 ·

Re: xTVAL Compliance restriction proposal

I focused on the HW writes to mtval when I described the Rocket core's behavior to Allen. The behavior for SW writes is that it unconditionally sign-extends from the most-significant implemented bit:

By andrew@... · #165 ·

Re: xTVAL Compliance restriction proposal

Allen, How is compliance testing going to handle this issue for software (versus hardware) writes to *tval CSRs? For example, when software writes stval with an address, how is the validity judged?

By Greg Favor · #164 ·

Re: xTVAL Compliance restriction proposal

Yes: X (our implementation conforms to this constraint or implements XLEN bits)

By Greg Favor · #163 ·

Re: xTVAL Compliance restriction proposal

When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says: Implementations may convert some invalid address patterns into

By andrew@... · #162 ·

xTVAL Compliance restriction proposal

When address-related exceptions occur, the xTVAL CSR is written with the faulting effective address. However, the spec also says: Implementations may convert some invalid address patterns into

By Allen Baum · #161 ·

Re: Boot code awareness of the Hypervisor extension

It certainly has been a goal, e.g., the CLIC was designed so that M-mode software that's oblivious to the CLIC still runs correctly on systems with the CLIC. I don't think there's a clear statement of

By andrew@... · #160 ·

Re: Boot code awareness of the Hypervisor extension

Can someone provide a definitive answer (Andrew?) as to the architectural intent of whether implementations supporting new architecture extensions must maintain backward compatibility with "legacy" M

By Greg Favor · #159 ·

Re: Address Mapping Questions

A bit more on that. There are a few debug CSRs which can be accessed as both CSRs and as Debug registers, specifically for communication. Otherwise, debug registers are in their own address space, and

By Allen Baum · #158 ·

Re: Address Mapping Questions

In re. your other question: > Another question: are CSRs also memory mapped? In debug mode? No, CSRs are not specified as memory-mapped (an implementation may choose to do so), even in Debug

By Nikhil Rishiyur · #157 ·

Re: Address Mapping Questions

It's something that could conceivably be standardized by the Unix platform task group, but I'm unaware as to whether that's in their plan of record.

By andrew@... · #156 ·

Re: Address Mapping Questions

Thanks Andrew - yes this de facto is great information. Is there any platform-level effort to convert this to a standard? Best Regards Nagendra

By Nagendra Gulur · #155 ·

1161 - 1180 of 1334

Home Hashtags Subgroups Terms