Re: Extending the number of PMP entries


Hardwired nonzero PMP registers are likely to start at the zeroth entry, because that way they have highest priority.  If they came at the end, writable PMPs could override them.

Once we admit that hardwired PMPs will sometimes/always be at the front, mandating that those hardwired PMPs contain only nonzero values seems a little silly.  It's harmless if some of the hardwired PMP registers up front are zero and some are nonzero.

And as you point out, some vendors currently have hardwired-zero PMPs at the end.

Between these observations, placing a mandate on where the block of hardwired-zero PMPs must live seems impractical.

On Wed, May 27, 2020 at 9:38 PM Allen Baum <allen.baum@...> wrote:
I don’t think I understand the your comment, Andrew. I interpreted Tariq saying we essentially restrict RdOnly zero entries to always be the larger numbered ones.
(Sort is the way that HartIndexes are assigned in rhe debug spec) then you can do a binary search to discover the number of potentially non-zero (writable) entries.

I dont think this is strictly backwards compatible,  but there’s a good chance that any implementation with PMP entries does it that way.

There may be some RdOnly-nonzero entries below the RdOnly zero entries- but that just means you do a binary search. Only  then so you need to check one by one.

Join to automatically receive all group messages.