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 !

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

 

 


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 !

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

 

 


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 !

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

 

 


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 !

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

 

 


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 !

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

 

 


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 !

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

 

 


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 !

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

 

 


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 !

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

 

 


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 !

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

 

 


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 !

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

 

 


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 !

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

 

 


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 !

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

 

 


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.


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.


Andrew Waterman
 

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.


Andrew Waterman
 

I've merged the pull request, but comments are obviously still welcome.  I recommend adding them on github at https://github.com/riscv/riscv-isa-manual/pull/525 to reduce the likelihood that they get lost.


On Fri, May 22, 2020 at 3:31 PM Andrew Waterman <andrew@...> wrote:
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 !

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

 

 


Allen Baum
 

The only reason that you might want to enforce some ordering is just so setup code doesn't have to check every single entry to see if it's writable or not. 
That is not a great reason for something that is only executed once at boot time.

On Sun, May 31, 2020 at 5:13 PM Andrew Waterman <andrew@...> wrote:
I've merged the pull request, but comments are obviously still welcome.  I recommend adding them on github at https://github.com/riscv/riscv-isa-manual/pull/525 to reduce the likelihood that they get lost.

On Fri, May 22, 2020 at 3:31 PM Andrew Waterman <andrew@...> wrote:
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 !

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

 

 


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

yes, fair enough.

Leaving it unrestricted is certainly the most flexible way

 

Tariq

 

From: tech-privileged@... [mailto:tech-privileged@...] On Behalf Of Allen Baum
Sent: 01 June 2020 23:26
To: Andrew Waterman <andrew@...>
Cc: Tariq Kurd <tariq.kurd@...>; tech-privileged@...
Subject: Re: [RISC-V] [tech-privileged] Extending the number of PMP entries

 

The only reason that you might want to enforce some ordering is just so setup code doesn't have to check every single entry to see if it's writable or not. 

That is not a great reason for something that is only executed once at boot time.

 

On Sun, May 31, 2020 at 5:13 PM Andrew Waterman <andrew@...> wrote:

I've merged the pull request, but comments are obviously still welcome.  I recommend adding them on github at https://github.com/riscv/riscv-isa-manual/pull/525 to reduce the likelihood that they get lost.

 

On Fri, May 22, 2020 at 3:31 PM Andrew Waterman <andrew@...> wrote:

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 !

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

 

 


Mario Achkar
 

Hello,

Sorry about reviving an old post but I would like to verify as I do not find this clear in the privileged draft.
If a decision is taken to implement exactly 16 PMP registers, should accesses to configuration/address registers outside of these 16 cause an illegal instruction exception or simply writes are ignored and reads hardwired to 0.
Or are both of the above allowed? If so, what is the best approach for future products.


Best,
Mario.


Andrew Waterman
 



On Fri, Oct 2, 2020 at 1:53 AM Mario Achkar <machkar@...> wrote:

Hello,

Sorry about reviving an old post but I would like to verify as I do not find this clear in the privileged draft.
If a decision is taken to implement exactly 16 PMP registers, should accesses to configuration/address registers outside of these 16 cause an illegal instruction exception or simply writes are ignored and reads hardwired to 0.
Or are both of the above allowed? If so, what is the best approach for future products.

The 16-PMP scheme is the only ratified one.  It's highly unlikely, but the CSRs allocated to the 64-PMP scheme might not ultimately be so purposed.  The most conservative option is to stick to the ratified spec.

Best,
Mario.