Στις 2020-02-13 22:30, John Hauser έγραψε: S/U mode doesn't have access to PMP registers so it's not possible to distinguish between an access fault e.g. due to a bug on an application /

I'm afraid I agree with John. I asked the same question myself some months ago - but less forcefully. :-) On one level, I agree with John here. But MXR and MPRV were set up when M mode never had

I concur with JohnH's reasoning. Omitting the new cause code does not remove any essential functionality, since M-mode software or debugger software can examine the protection and translation

Nick Kossifidis wrote: I'm sorry to say, providing information to a debugger is not usually considered a valid reason for additional RISC-V exception codes when the same information can be extracted

>A while ago, I expressed opposition to consuming one of the remaining pmpcfg bits because it seemed, >at the time, that the goals of this proposal could be accomplished without doing so. If that is

Hello John and thanks for your feedback, The new mechanism (when MML is set) introduces a barrier between S/U mode and M mode, We want to be able to distinguish between an access fault due to

Sure, something custom would work. And what you suggested is a good possibility. But I brought it up because I thought the use case might be more broadly applicable and maybe some combination in

Bill Huffman wrote: Concerning PMP, that's what I was suggesting, yes. I believe the answer can be physical memory attributes (PMAs), which apply in addition to the software-programmable PMP

Hello John, I'm thinking positively about your proposal for a 2-bit MSL field and a 2-bit PL field per PMP entry. But I'm still a little concerned by what you say below... Chipmakers sometimes

Sean Halle wrote: Hi Sean, I'm afraid I wasn't completely clear on what question you're asking. Is your baseline case a Fedora OS that doesn't configure PMP? I don't know the current behavior of

Pull request is here: https://github.com/riscv/riscv-isa-manual/pull/484

Thank you John, Joe, Greg and Andrew for the interesting discussion. One general question, at more of a management level. Our architecture has 16 harts per core. That means that the CSR logic is one

A while ago, I expressed opposition to consuming one of the remaining pmpcfg bits because it seemed, at the time, that the goals of this proposal could be accomplished without doing so. If that is

I wrote: "I assume there is also an independent DMC bit (Default Memory Closed)." - John Hauser

As promised, here is my suggestion for modifying the TEE Task Group's "PMP Enhancements" proposal to have four security levels, to support a larger set of use cases. Instead of the two bits MML and

It seems like the current trade-off in supported use cases is due to the combination of two constraints: backward compatibility and avoiding use of a Reserved PMP bit. A year ago the exact degree of

For 4.. As we discussed in the meeting we agree with the use case, lock is existing in current PMP. The current PMP enhancement proposal tries to be back compatible and thus does not try to address

I wrote: Correction: I believe that should say "... implicitly grants read permission to S/U modes when in M mode and MXR = 1". This is relevant only when MPRV = 1 and MPP = 0 or 1, so it's a rather

Hello all, I've been studying the TEE Task Group's "PMP Enhancements" proposal with great interest off-and-on for several weeks. I definitely agree with the intention of the proposal, but I see

ACK, I'll update the doc accordingly. Regards, Nick