Date   

Re: Non-idempotent PMA and table walk accesses

Greg Favor
 

For reference here is ARMv8's definition of idempotency (which includes side-effects):

The Normal memory attribute is appropriate for locations of memory that are idempotent, meaning that they exhibit all of the following properties:
— Read accesses can be repeated with no side-effects.
— Repeated read accesses return the last value written to the resource being read.
— Read accesses can fetch additional memory locations with no side-effects.
— Write accesses can be repeated with no side-effects if the contents of the location accessed are unchanged between the repeated writes or as the result of an exception, as described in this section.
— Unaligned accesses can be supported.
— Accesses can be merged before accessing the target memory system.

Put very concisely (and stripped down a bit):  Reads and writes can be repeated without side-effects, and reads return the last value written.  In addition accesses can be misaligned and can be merged.

Greg

On Mon, May 18, 2020 at 5:35 PM Bill Huffman <huffman@...> wrote:

On 5/18/20 5:10 PM, David Kruckemyer wrote:

EXTERNAL MAIL

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 repeatable with the same result) or in a broader sense (e.g. inclusive of any side-effects even if the values at the location don't change).

I've always assumed the "non-idempotent" attribute meant that a read may not return the last value written or that repeated reads may not return the same value, not that the behavior included side-effects that are observable elsewhere. What is the consensus regarding this?

Cheers,
David

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 tiny amounts of electromigration.  I don't think it includes incrementing performance counters or shifting the results of predictors either.  Not sure how many things actually fit between your definition and mine.  Perhaps not many in real implementations.

      Bill


Re: Non-idempotent PMA and table walk accesses

Greg Favor
 

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 effects.

It seems like "reads return the last value written" also needs to be part of the explicit definition.  A location may have no side-effects, but reads still may not always return the last written value (a device status register being the classic example).

PMA-wise the Priv spec separates out alignment constraints (as a separate PMA), and makes no mention of mergability or non-mergability as a PMA.  Shouldn't the latter be an explicit PMA (akin to the write merging distinctions that x86 and ARMv8 draw between their various memory types)?

Greg

On Mon, May 18, 2020 at 6:42 PM Greg Favor <gfavor@...> wrote:
For reference here is ARMv8's definition of idempotency (which includes side-effects):

The Normal memory attribute is appropriate for locations of memory that are idempotent, meaning that they exhibit all of the following properties:
— Read accesses can be repeated with no side-effects.
— Repeated read accesses return the last value written to the resource being read.
— Read accesses can fetch additional memory locations with no side-effects.
— Write accesses can be repeated with no side-effects if the contents of the location accessed are unchanged between the repeated writes or as the result of an exception, as described in this section.
— Unaligned accesses can be supported.
— Accesses can be merged before accessing the target memory system.

Put very concisely (and stripped down a bit):  Reads and writes can be repeated without side-effects, and reads return the last value written.  In addition accesses can be misaligned and can be merged.

Greg

On Mon, May 18, 2020 at 5:35 PM Bill Huffman <huffman@...> wrote:

On 5/18/20 5:10 PM, David Kruckemyer wrote:

EXTERNAL MAIL

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 repeatable with the same result) or in a broader sense (e.g. inclusive of any side-effects even if the values at the location don't change).

I've always assumed the "non-idempotent" attribute meant that a read may not return the last value written or that repeated reads may not return the same value, not that the behavior included side-effects that are observable elsewhere. What is the consensus regarding this?

Cheers,
David

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 tiny amounts of electromigration.  I don't think it includes incrementing performance counters or shifting the results of predictors either.  Not sure how many things actually fit between your definition and mine.  Perhaps not many in real implementations.

      Bill


Re: Non-idempotent PMA and table walk accesses

David Kruckemyer
 

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 state, so that even if the underlying memory location was idempotent in the "reads return the last value written" sense, system side-effects would make the location non-idempotent. But that doesn't neatly apply to performance counters (and possibly other state).

This just seems to highlight is that architectural specification is hard.

Returning to my initial query, I'm still trying to understand what table walks to non-idempotent locations mean generally. If we assume the colloquial meaning of non-idempotent is "don't speculate" (ignoring the side-effects of the location or on other state), it would seem that a table walk access to a non-idempotent location could not be performed until all previous instructions were guaranteed not to trap. Is that the intent?

Regardless, I'll put in another plug for commentary stating that the architecture strongly recommends that memory management data structures be located in idempotent regions.

Cheers,
David


On Mon, May 18, 2020 at 6:56 PM Greg Favor <gfavor@...> wrote:
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 effects.

It seems like "reads return the last value written" also needs to be part of the explicit definition.  A location may have no side-effects, but reads still may not always return the last written value (a device status register being the classic example).

PMA-wise the Priv spec separates out alignment constraints (as a separate PMA), and makes no mention of mergability or non-mergability as a PMA.  Shouldn't the latter be an explicit PMA (akin to the write merging distinctions that x86 and ARMv8 draw between their various memory types)?

Greg

On Mon, May 18, 2020 at 6:42 PM Greg Favor <gfavor@...> wrote:
For reference here is ARMv8's definition of idempotency (which includes side-effects):

The Normal memory attribute is appropriate for locations of memory that are idempotent, meaning that they exhibit all of the following properties:
— Read accesses can be repeated with no side-effects.
— Repeated read accesses return the last value written to the resource being read.
— Read accesses can fetch additional memory locations with no side-effects.
— Write accesses can be repeated with no side-effects if the contents of the location accessed are unchanged between the repeated writes or as the result of an exception, as described in this section.
— Unaligned accesses can be supported.
— Accesses can be merged before accessing the target memory system.

Put very concisely (and stripped down a bit):  Reads and writes can be repeated without side-effects, and reads return the last value written.  In addition accesses can be misaligned and can be merged.

Greg

On Mon, May 18, 2020 at 5:35 PM Bill Huffman <huffman@...> wrote:

On 5/18/20 5:10 PM, David Kruckemyer wrote:

EXTERNAL MAIL

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 repeatable with the same result) or in a broader sense (e.g. inclusive of any side-effects even if the values at the location don't change).

I've always assumed the "non-idempotent" attribute meant that a read may not return the last value written or that repeated reads may not return the same value, not that the behavior included side-effects that are observable elsewhere. What is the consensus regarding this?

Cheers,
David

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 tiny amounts of electromigration.  I don't think it includes incrementing performance counters or shifting the results of predictors either.  Not sure how many things actually fit between your definition and mine.  Perhaps not many in real implementations.

      Bill


Re: Non-idempotent PMA and table walk accesses

Andrew Waterman
 



On Mon, May 18, 2020 at 3:26 PM Andrew Waterman <andrew@...> wrote:


On Mon, May 18, 2020 at 2:58 PM David Kruckemyer <dkruckemyer@...> wrote:
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 answer is probably "yes." However, I'm having a hard time understanding a system design in which such a table walk would be practical. Can someone provide a practical use-case for walking non-idempotent locations?

If no such use-case exists, would people object to imposing a restriction on table walk accesses to locations with the non-idempotent PMA? Or at least a comment strongly suggesting that platforms won't support that behavior?

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 page-table reads and hardware page-table writes are supported."

I'd support adding a note that permitting page-table accesses to idempotent regions is

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

discouraged.  Banning it seems a little harsh, though I see where you're coming from.


Cheers,
David


Re: Non-idempotent PMA and table walk accesses

Nikhil Rishiyur
 

>    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 repeatable with the same result) or in a
>    broader sense (e.g. inclusive of any side-effects even if the
>    values at the location don't change).

Whether one treats a performance counter as a 'benign side effect' or
not depends on what one does with it.  It could be merely passive
instrumentation to obtaim meta-information about program behavior. But
if the counter itself is observable to the program and can affect its
future behavior, then it's more serious.

I would avoid _requiring_ anything about itempotency in the spec, and
just leave it to commentary like this for the system designer to be
aware of the issues and to decide whether PTWs in their system can
happen in idempotent regions or not.

Nikhil


Re: Non-idempotent PMA and table walk accesses

David Kruckemyer
 



On Tue, May 19, 2020 at 5:10 AM Nikhil Rishiyur <nikhil@...> wrote:
>    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 repeatable with the same result) or in a
>    broader sense (e.g. inclusive of any side-effects even if the
>    values at the location don't change).

Whether one treats a performance counter as a 'benign side effect' or
not depends on what one does with it.  It could be merely passive
instrumentation to obtaim meta-information about program behavior. But
if the counter itself is observable to the program and can affect its
future behavior, then it's more serious.

Agreed that the counter in your example can be important to system operation.
 

I would avoid _requiring_ anything about itempotency in the spec, and
just leave it to commentary like this for the system designer to be
aware of the issues and to decide whether PTWs in their system can
happen in idempotent regions or not.

OK, I'm fine with this. I still think this PMA confounds the notion of idempotency with speculation control (i.e. whether a location has side-effects can be independent of whether SW wants to limit speculation to that location), which is ultimately a separate issue from the PTW issue.
 

Nikhil


Extending the number of PMP entries

Mr Tariq Kurd <tariq.kurd@...>
 

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

 

What do people think?

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Andrew Waterman
 



On Thu, May 21, 2020 at 8:17 AM Mr Tariq Kurd <tariq.kurd@...> wrote:

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

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.

 

What do people think?

👍

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Mr Tariq Kurd <tariq.kurd@...>
 

Hi Andrew,

 

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

 

Tariq

 

From: Andrew Waterman [mailto:andrew@...]
Sent: 21 May 2020 17:50
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

 

 

On Thu, May 21, 2020 at 8:17 AM Mr Tariq Kurd <tariq.kurd@...> wrote:

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

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.

 

 

What do people think?

👍

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Andrew Waterman
 

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 entries manifested in several places in the document.


On Fri, May 22, 2020 at 12:30 AM Tariq Kurd <tariq.kurd@...> wrote:

Hi Andrew,

 

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

 

Tariq

 

From: Andrew Waterman [mailto:andrew@...]
Sent: 21 May 2020 17:50
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

 

 

On Thu, May 21, 2020 at 8:17 AM Mr Tariq Kurd <tariq.kurd@...> wrote:

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

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.

 

 

What do people think?

👍

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Abner Chang <abner.chang@...>
 

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 to RISC-V configurations structure.

 

-          Abner

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Saturday, May 23, 2020 6:31 AM
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 entries manifested in several places in the document.

 

 

On Fri, May 22, 2020 at 12:30 AM Tariq Kurd <tariq.kurd@...> wrote:

Hi Andrew,

 

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

 

Tariq

 

From: Andrew Waterman [mailto:andrew@...]
Sent: 21 May 2020 17:50
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

 

 

On Thu, May 21, 2020 at 8:17 AM Mr Tariq Kurd <tariq.kurd@...> wrote:

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

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.

 

 

What do people think?

👍

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Andrew Waterman
 

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 doesn't belong in the configuration structure, but lazier programmers disagree.


On Sun, May 24, 2020 at 7:53 PM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote:

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 to RISC-V configurations structure.

 

-          Abner

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Saturday, May 23, 2020 6:31 AM
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 entries manifested in several places in the document.

 

 

On Fri, May 22, 2020 at 12:30 AM Tariq Kurd <tariq.kurd@...> wrote:

Hi Andrew,

 

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

 

Tariq

 

From: Andrew Waterman [mailto:andrew@...]
Sent: 21 May 2020 17:50
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

 

 

On Thu, May 21, 2020 at 8:17 AM Mr Tariq Kurd <tariq.kurd@...> wrote:

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

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.

 

 

What do people think?

👍

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Anup Patel
 

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

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Abner Chang
Sent: 25 May 2020 08:22
To: Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 to RISC-V configurations structure.

 

  • Abner

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Saturday, May 23, 2020 6:31 AM
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 entries manifested in several places in the document.

 

 

On Fri, May 22, 2020 at 12:30 AM Tariq Kurd <tariq.kurd@...> wrote:

Hi Andrew,

 

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

 

Tariq

 

From: Andrew Waterman [mailto:andrew@...]
Sent: 21 May 2020 17:50
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

 

 

On Thu, May 21, 2020 at 8:17 AM Mr Tariq Kurd <tariq.kurd@...> wrote:

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

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.

 

 

What do people think?

👍

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Abner Chang <abner.chang@...>
 

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 existence of features using exception.

How PMP structure is defined is not in the scope of Configuration Structure. However, the capability which is not defined in the privilege spec such as the number of PMP entries (0, 16, 64) is good to defined in Configuration Structure, so does CLIC base address, ePMP, SPMP and etc..

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Monday, May 25, 2020 12:07 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>
Cc: Tariq Kurd <tariq.kurd@...>; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 doesn't belong in the configuration structure, but lazier programmers disagree.

 

On Sun, May 24, 2020 at 7:53 PM Chang, Abner (HPS SW/FW Technologist) <abner.chang@...> wrote:

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 to RISC-V configurations structure.

 

-          Abner

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Saturday, May 23, 2020 6:31 AM
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 entries manifested in several places in the document.

 

 

On Fri, May 22, 2020 at 12:30 AM Tariq Kurd <tariq.kurd@...> wrote:

Hi Andrew,

 

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

 

Tariq

 

From: Andrew Waterman [mailto:andrew@...]
Sent: 21 May 2020 17:50
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

 

 

On Thu, May 21, 2020 at 8:17 AM Mr Tariq Kurd <tariq.kurd@...> wrote:

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

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.

 

 

What do people think?

👍

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Abner Chang <abner.chang@...>
 

Missed this mail while I was replying to Andrew. Same feedback to your comment in that reply.

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Anup Patel
Sent: Monday, May 25, 2020 1:31 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Abner Chang
Sent: 25 May 2020 08:22
To: Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 to RISC-V configurations structure.

 

-          Abner

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Saturday, May 23, 2020 6:31 AM
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 entries manifested in several places in the document.

 

 

On Fri, May 22, 2020 at 12:30 AM Tariq Kurd <tariq.kurd@...> wrote:

Hi Andrew,

 

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

 

Tariq

 

From: Andrew Waterman [mailto:andrew@...]
Sent: 21 May 2020 17:50
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

 

 

On Thu, May 21, 2020 at 8:17 AM Mr Tariq Kurd <tariq.kurd@...> wrote:

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

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.

 

 

What do people think?

👍

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Anup Patel
 

You are free to add it in “RISC-V configuration structure” but from Linux, Hypervisors and M-mode RUNTIME firmware perspective we don’t’ need it.

 

All these software will:

  1. Either use illegal instruction traps if they are running in M-mode
  2. Use device tree to describe number of PMP registers in CPU DT node

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Abner Chang
Sent: 25 May 2020 11:52
To: Anup Patel <Anup.Patel@...>; Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

Missed this mail while I was replying to Andrew. Same feedback to your comment in that reply.

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Anup Patel
Sent: Monday, May 25, 2020 1:31 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Abner Chang
Sent: 25 May 2020 08:22
To: Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 to RISC-V configurations structure.

 

  • Abner

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Saturday, May 23, 2020 6:31 AM
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 entries manifested in several places in the document.

 

 

On Fri, May 22, 2020 at 12:30 AM Tariq Kurd <tariq.kurd@...> wrote:

Hi Andrew,

 

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

 

Tariq

 

From: Andrew Waterman [mailto:andrew@...]
Sent: 21 May 2020 17:50
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

 

 

On Thu, May 21, 2020 at 8:17 AM Mr Tariq Kurd <tariq.kurd@...> wrote:

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

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.

 

 

What do people think?

👍

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Abner Chang <abner.chang@...>
 

Same understanding here Anup. The most of uses are runtime debug, trace, compliance validation and POST time firmware (configures H/W and also builds up DT for the software you mentioned).

 

Abner

 

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Anup Patel
Sent: Monday, May 25, 2020 3:31 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

You are free to add it in “RISC-V configuration structure” but from Linux, Hypervisors and M-mode RUNTIME firmware perspective we don’t’ need it.

 

All these software will:

  1. Either use illegal instruction traps if they are running in M-mode
  2. Use device tree to describe number of PMP registers in CPU DT node

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Abner Chang
Sent: 25 May 2020 11:52
To: Anup Patel <Anup.Patel@...>; Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

Missed this mail while I was replying to Andrew. Same feedback to your comment in that reply.

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Anup Patel
Sent: Monday, May 25, 2020 1:31 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Abner Chang
Sent: 25 May 2020 08:22
To: Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 to RISC-V configurations structure.

 

-          Abner

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Saturday, May 23, 2020 6:31 AM
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 entries manifested in several places in the document.

 

 

On Fri, May 22, 2020 at 12:30 AM Tariq Kurd <tariq.kurd@...> wrote:

Hi Andrew,

 

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

 

Tariq

 

From: Andrew Waterman [mailto:andrew@...]
Sent: 21 May 2020 17:50
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

 

 

On Thu, May 21, 2020 at 8:17 AM Mr Tariq Kurd <tariq.kurd@...> wrote:

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

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.

 

 

What do people think?

👍

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Mr Tariq Kurd <tariq.kurd@...>
 

Thanks for this Andrew, it’s really useful.

My only comment is:

 

“Up to 64 PMP entries are supported. Implementations may implement zero, 16, or 64 PMP CSRs. All PMP CSR fields are WARL and may be hardwired to zero. PMP CSRs are only accessible to M-mode.”

 

Whether we should require people to only hardwire the highest numbered entries to zero. Otherwise, in theory, a discovery mechanism which checks which PMP CSRs are writeable will need to probe all of them, instead of starting at the highest number (15 or 63) and then probing downwards until it finds the first writeable one. So there should be one writeable block starting from 0 and optionally one read-only-zero block in the highest numbered entries only.

 

Tariq

 

From: Chang, Abner (HPS SW/FW Technologist) [mailto:abner.chang@...]
Sent: 25 May 2020 09:24
To: Anup Patel <anup.patel@...>; Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: RE: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

Same understanding here Anup. The most of uses are runtime debug, trace, compliance validation and POST time firmware (configures H/W and also builds up DT for the software you mentioned).

 

Abner

 

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Anup Patel
Sent: Monday, May 25, 2020 3:31 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

You are free to add it in “RISC-V configuration structure” but from Linux, Hypervisors and M-mode RUNTIME firmware perspective we don’t’ need it.

 

All these software will:

  1. Either use illegal instruction traps if they are running in M-mode
  2. Use device tree to describe number of PMP registers in CPU DT node

 

Regards,

Anup

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Abner Chang
Sent: 25 May 2020 11:52
To: Anup Patel <Anup.Patel@...>; Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

Missed this mail while I was replying to Andrew. Same feedback to your comment in that reply.

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Anup Patel
Sent: Monday, May 25, 2020 1:31 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@...>; Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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

 

From: tech-privileged@... <tech-privileged@...> On Behalf Of Abner Chang
Sent: 25 May 2020 08:22
To: Andrew Waterman <andrew@...>; Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 to RISC-V configurations structure.

 

-        Abner

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Andrew Waterman
Sent: Saturday, May 23, 2020 6:31 AM
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] 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 entries manifested in several places in the document.

 

 

On Fri, May 22, 2020 at 12:30 AM Tariq Kurd <tariq.kurd@...> wrote:

Hi Andrew,

 

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

 

Tariq

 

From: Andrew Waterman [mailto:andrew@...]
Sent: 21 May 2020 17:50
To: Tariq Kurd <tariq.kurd@...>
Cc: tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

 

 

On Thu, May 21, 2020 at 8:17 AM Mr Tariq Kurd <tariq.kurd@...> wrote:

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 space can allow up to 64 PMP entries (unless CSRs have been allocated which I don’t know about).

0x3A4 – 0x3AF could become pmpcfg4-15

0x3C0 – 0x3EF could become pmpaddr16-63

 

64 entries would be more than enough (I don’t envisage needing more than 32), but I don’t know about other users.

 

I’m happy to allocate the PMP entries in blocks of 16, for example, and make higher numbered unused entries read-only-zero to save area.

So in our case we would implement the CSRs for 32 entries, but entries 20-31 would be read-only-zero

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.

 

 

What do people think?

👍

 

Tariq

 

Tariq Kurd

Processor Design I RISC-V Cores, Bristol

Tel: none I Mobile: +447711069063 I E-mail: Tariq.Kurd@...

Company: Huawei I Address: 160 Aztec West, Bristol, UK, BS32 4TU

315px-Huawei    http://www.huawei.com

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it !

本邮件及其附件含有华为公司的保密信息,仅限于发送给上面 地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件!

 

 


Re: Extending the number of PMP entries

Andrew Waterman
 



On Wed, May 27, 2020 at 5:15 AM Tariq Kurd <tariq.kurd@...> wrote:

Thanks for this Andrew, it’s really useful.

My only comment is:

 

“Up to 64 PMP entries are supported. Implementations may implement zero, 16, or 64 PMP CSRs. All PMP CSR fields are WARL and may be hardwired to zero. PMP CSRs are only accessible to M-mode.”

 

Whether we should require people to only hardwire the highest numbered entries to zero. Otherwise, in theory, a discovery mechanism which checks which PMP CSRs are writeable will need to probe all of them, instead of starting at the highest number (15 or 63) and then probing downwards until it finds the first writeable one. So there should be one writeable block starting from 0 and optionally one read-only-zero block in the highest numbered entries only.


I see what you're getting at, but since some vendors will (rightly) choose to hardwire some PMP registers, the sentiment seems impractical to enforce.


Re: Extending the number of PMP entries

Allen Baum
 

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.

121 - 140 of 1210