tech-privileged@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

Andrew, the intention of Configuration Structure task group is to define RISC-V core/hart hardware features in the configuration structure and retrieved by M-mode software without probing the

By Abner Chang <abner.chang@...> · #134 ·

Re: Extending the number of PMP entries

This is not needed. We can easily probe number of PMP registers using illegal instruction traps. Look at latest OpenSBI sources. Regards, Anup

By Anup Patel · #133 ·

Re: Extending the number of PMP entries

The situation hasn't changed: it has always been straightforward to write M-mode software to detect the number of PMP registers at runtime, relying on precise exceptions. IMO, that means this stuff

By andrew@... · #132 ·

Re: Extending the number of PMP entries

Just writing to confirm that there is no information regards to the # of PMP entries supported by hart mentioned in privilege spec . If my understanding is correct, then this information is good to go

By Abner Chang <abner.chang@...> · #131 ·

Re: Extending the number of PMP entries

I've made a pull request to extend the number of PMP entries, and have attached the compiled PDF for convenience. Feedback and error detection are appreciated: the fact that there used to be 16 PMP

By andrew@... · #130 ·

Re: Extending the number of PMP entries

Hi Andrew, That’s fine for me. Implementing 0 / 16 / 64 PMP entries is ok Tariq

By Mr Tariq Kurd <tariq.kurd@...> · #129 ·

Re: Extending the number of PMP entries

The other option here is to allocate all 48 at once (and for your example 20-63 would be read-only-zero). This might be slightly easier for software portability and is neutral for HW cost. 👍

By andrew@... · #128 ·

Extending the number of PMP entries

Hi everyone, Can we allocate more CSRs so that we can have more PMP entries available? We already have one implementation which requires 20 PMP entries, for example. Currently the CSR address

By Mr Tariq Kurd <tariq.kurd@...> · #127 ·

Re: Non-idempotent PMA and table walk accesses

Agreed that the counter in your example can be important to system operation. OK, I'm fine with this. I still think this PMA confounds the notion of idempotency with speculation control (i.e.

By David Kruckemyer · #126 ·

Re: Non-idempotent PMA and table walk accesses

> That sounds a bit like a performance counter to me, but it does > raise an interesting question whether "idempotent" in the > architectural sense is idempotent in a mathematical sense >

By Nikhil Rishiyur · #125 ·

Re: Non-idempotent PMA and table walk accesses

Of course I meant “non-idempotent”... discouraging page-table accesses to idempotent regions might raise some hackles.

By andrew@... · #124 ·

Re: Non-idempotent PMA and table walk accesses

To clarify, in my previous email, I was taking a rather narrow view of the idempotent/non-idempotent attribute as applied to a memory location. One could broaden that definition to include system

By David Kruckemyer · #123 ·

Re: Non-idempotent PMA and table walk accesses

P.S. This stripped down ARMv8 definition goes a little further than what is currently in the Privileged spec - which only says that accesses are non-idempotent if reads and/or writes have any side

By Greg Favor · #122 ·

Re: Non-idempotent PMA and table walk accesses

For reference here is ARMv8's definition of idempotency (which includes side-effects): Put very concisely (and stripped down a bit): Reads and writes can be repeated without side-effects, and reads

By Greg Favor · #121 ·

Re: Non-idempotent PMA and table walk accesses

On 5/18/20 5:10 PM, David Kruckemyer wrote: I've always assumed that it included any side-effects that mattered to the program. It obviously does not include bringing the demise of a chip nearer with

By Bill Huffman · #120 ·

Re: Non-idempotent PMA and table walk accesses

That sounds a bit like a performance counter to me, but it does raise an interesting question whether "idempotent" in the architectural sense is idempotent in a mathematical sense (i.e. operations are

By David Kruckemyer · #119 ·

Re: Non-idempotent PMA and table walk accesses

Although I haven't seen any such implementation, I would imagine that a non-idempotent region that was, say, counting accesses to each address as a side-effect of each access may be a "benign" kind of

By Nikhil Rishiyur · #118 ·

Re: Non-idempotent PMA and table walk accesses

The specification machinery exists to allow implementations to impose such a restriction: "For systems with page-based virtual memory, I/O and memory regions can specify which combinations of hardware

By andrew@... · #117 ·

Non-idempotent PMA and table walk accesses

Hi all, I have a simple question: does the architecture allow table walk accesses (reads or writes) to regions with the non-idempotent PMA? The architecture doesn't explicitly disallow it, so the

By David Kruckemyer · #116 ·

Re: hstatus.VTW for WFI

I wrote: I've created a pull request for the RISC-V privileged manual: https://github.com/riscv/riscv-isa-manual/pull/523 Comments welcome. - John Hauser

By John Hauser · #115 ·

1201 - 1220 of 1334

Home Hashtags Subgroups Terms