Hello The privileged architecture says that when returning from interrupt with MRET, MPIE is set to 1 (and MPP is set to U). What is the rational behind ? Is it still in the context of supporting

Hi TEE group, I would like to give a quick update on ePMP spec. Public review We are still waiting for unpriv group to approve new CSR address assignment. It’s been pending for a while because

Yes. It's not fully in my control, but I'm hoping within the next week or two. Greg

(+platforms, which Mark had added in.) Thanks for the quick reply Greg. Good to know it is of concern to others.😊 I assume the specification will be posted for public review in the

Fancy you should ask. :) A fast-track extension is being put together (and going thru some pre-review by a couple of key people) and hopefully should be put to initial public review very soon. That

+platform -------- sent from a mobile device. please forgive any typos.

Hi, I have some questions about the hpm CSRs. There is a conspicuous lack of an interrupt associated with a counter overflow. Are custom interrupts expected to be provided in a RISC-V

Yes. Thanks for catching that. (And the same applies for vstimecmp.) Greg

Presumably this should say "attempts to read or write the stimecmp register..."? Jonathan

That is the collective view. In general, machine-level software is expected to know what it needs to know about the hart on which it is running. (There's that pesky discovery thing again. :) ) Greg

Yea, that makes sense, though I'd say it's not strictly backwards compatible; old Mcode will silently fail. I will not complain if we make a blanket statement that Mcode backwards compatibility is not

This text takes the same approach as much of the rest of the Supervisor chapter in the Priv spec, i.e. the existing and coming new discovery methods apply equally to these new CSRs as to all existing

So to know if M-mode can fake an Smode counter interrupt or not,(which it can currently do), Mmode SW needs to attempt to write STMECMP and see if it traps? OR attempt to set the STIP bit and see if

Hi all, Recently the TSC established a lightweight "fast track" architecture extension process that small, straightforward, relatively uncontentious arch extension proposals can utilize. Andrew and I

thank you for your comment 1. for now, i am only proposing the addition of the ARM extensions to sv57. the reason being that current linux, for ARM, can function with this extension 2. for

i found this after some time. this is an extensive set of benchmarks. comparing KASLR enabled and not enabled draw your own conclusions perhaps the summary tells it

Hello Steven, Στις 2020-11-26 18:04, swallach έγραψε: I'm trying to understand from your comments what ISA-related changes do you propose for Sv57/Sv64 other than the address space

attached at my comments. like everything else, performance is always a function of the implementation. same ISA, different implementation, different performance. there are several themes to this

RISC-V can already support KAISER now so I'm not sure why rv64 would need anything special for it? As a side note, that paper seriously understates the costs of KAISER. On other workloads it can be

this would take some time. but to begin separating kernel from user, provides both the first level of isolation. this can be further used for .hypervisor isolation trojan horse pointers