Date   

Re: Extending the number of PMP entries

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.


Re: Extending the number of PMP entries

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 !

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

 

 


Re: Extending the number of PMP entries

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 !

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

 

 


Re: Extending the number of PMP entries

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 !

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

 

 


Appearance of new M-mode CSR bits when Hypervisor is disabled

Greg Favor
 

The Hypervisor extension adds bits to some of the existing M-mode CSR's.  When this extension is not implemented, these bits are hardwired to zero. When the extension _is_ implemented these bits become either read/write or (in a few cases) hardwired to one.

On the one hand the hypervisor spec says that when misa.H=0 (i.e. the extension is "disabled"), "the hart behaves as though this extension were not implemented".  But where these various added M-mode CSR bits are described, they are defined to exist when "the hypervisor extension is implemented".

The former statement implies that these new bits must appear to be hardwired to zero when misa.H=0, while the latter statement implies that these new bits appear to be read/write or hardwired to one irrespective of misa.H (although presumably they have no functional effects when misa.H=0).

Which is the correct architectural intention?

Greg



Boot code awareness of the Hypervisor extension

Greg Favor
 

We have run across the situation of running "legacy" (i.e. current) boot code that naturally is unaware of the possible existence of the Hypervisor extension.  Since, on a platform that does implement the Hypervisor extension, misa.H is required to be reset to '1', there are architectural behavior changes that can trip up this boot code.  Both because the hypervisor extension is enabled and because new CSR's (some of which contain bits that, for example, affect the behavior of existing instructions) will remain uninitialized by this unaware boot code.

We suspect that the following is the view by the architecture:

Boot code that may run on platforms that may or may not support certain arch extensions (such as the Hypervisor extension) must be aware of their potential existence and be prepared to deal with misa indicating that they are or are not supported.

Conversely, unaware "legacy" boot code is not expected or required to run as-is on newer platforms that support newer arch extensions.  Such "old" boot code must be ported to run on platforms that implement new architecture extensions like the Hypervisor extension.  

Yes?

Greg


Re: Boot code awareness of the Hypervisor extension

Jonathan Behrens <behrensj@...>
 

I would expect the rule be that either the reset state properly initializes all the H-extension CSRs or the boot code. Thus if you want hardware to be backwards compatible with legacy boot code, you just have to make sure the reset state is correct. And if you don't care about backwards compatibility then you have the flexibility to not worry about the reset state and just configure things in the boot code.

Jonathan


On Wed, Jun 3, 2020 at 2:31 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
We have run across the situation of running "legacy" (i.e. current) boot code that naturally is unaware of the possible existence of the Hypervisor extension.  Since, on a platform that does implement the Hypervisor extension, misa.H is required to be reset to '1', there are architectural behavior changes that can trip up this boot code.  Both because the hypervisor extension is enabled and because new CSR's (some of which contain bits that, for example, affect the behavior of existing instructions) will remain uninitialized by this unaware boot code.

We suspect that the following is the view by the architecture:

Boot code that may run on platforms that may or may not support certain arch extensions (such as the Hypervisor extension) must be aware of their potential existence and be prepared to deal with misa indicating that they are or are not supported.

Conversely, unaware "legacy" boot code is not expected or required to run as-is on newer platforms that support newer arch extensions.  Such "old" boot code must be ported to run on platforms that implement new architecture extensions like the Hypervisor extension.  

Yes?

Greg


Re: Boot code awareness of the Hypervisor extension

Greg Favor
 

One issue is that the current Privileged spec requires that misa.H is reset to '1' if the Hypervisor extension is implemented.  Unaware boot code will leave that set and then problems will ensue later.

Greg


On Wed, Jun 3, 2020 at 11:46 AM Jonathan Behrens <behrensj@...> wrote:
I would expect the rule be that either the reset state properly initializes all the H-extension CSRs or the boot code. Thus if you want hardware to be backwards compatible with legacy boot code, you just have to make sure the reset state is correct. And if you don't care about backwards compatibility then you have the flexibility to not worry about the reset state and just configure things in the boot code.

Jonathan

On Wed, Jun 3, 2020 at 2:31 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
We have run across the situation of running "legacy" (i.e. current) boot code that naturally is unaware of the possible existence of the Hypervisor extension.  Since, on a platform that does implement the Hypervisor extension, misa.H is required to be reset to '1', there are architectural behavior changes that can trip up this boot code.  Both because the hypervisor extension is enabled and because new CSR's (some of which contain bits that, for example, affect the behavior of existing instructions) will remain uninitialized by this unaware boot code.

We suspect that the following is the view by the architecture:

Boot code that may run on platforms that may or may not support certain arch extensions (such as the Hypervisor extension) must be aware of their potential existence and be prepared to deal with misa indicating that they are or are not supported.

Conversely, unaware "legacy" boot code is not expected or required to run as-is on newer platforms that support newer arch extensions.  Such "old" boot code must be ported to run on platforms that implement new architecture extensions like the Hypervisor extension.  

Yes?

Greg


Re: Boot code awareness of the Hypervisor extension

Jonathan Behrens <behrensj@...>
 

Why would that be a problem? As long as you don't issue any HS-mode instructions or touch any of the hypervisor CSRs then any code should run the same.

Jonathan


On Wed, Jun 3, 2020 at 2:51 PM Greg Favor <gfavor@...> wrote:
One issue is that the current Privileged spec requires that misa.H is reset to '1' if the Hypervisor extension is implemented.  Unaware boot code will leave that set and then problems will ensue later.

Greg


On Wed, Jun 3, 2020 at 11:46 AM Jonathan Behrens <behrensj@...> wrote:
I would expect the rule be that either the reset state properly initializes all the H-extension CSRs or the boot code. Thus if you want hardware to be backwards compatible with legacy boot code, you just have to make sure the reset state is correct. And if you don't care about backwards compatibility then you have the flexibility to not worry about the reset state and just configure things in the boot code.

Jonathan

On Wed, Jun 3, 2020 at 2:31 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
We have run across the situation of running "legacy" (i.e. current) boot code that naturally is unaware of the possible existence of the Hypervisor extension.  Since, on a platform that does implement the Hypervisor extension, misa.H is required to be reset to '1', there are architectural behavior changes that can trip up this boot code.  Both because the hypervisor extension is enabled and because new CSR's (some of which contain bits that, for example, affect the behavior of existing instructions) will remain uninitialized by this unaware boot code.

We suspect that the following is the view by the architecture:

Boot code that may run on platforms that may or may not support certain arch extensions (such as the Hypervisor extension) must be aware of their potential existence and be prepared to deal with misa indicating that they are or are not supported.

Conversely, unaware "legacy" boot code is not expected or required to run as-is on newer platforms that support newer arch extensions.  Such "old" boot code must be ported to run on platforms that implement new architecture extensions like the Hypervisor extension.  

Yes?

Greg


Re: Boot code awareness of the Hypervisor extension

Greg Favor
 

But there is existing architecture functionality (e.g. the SRET instruction) that is affected by certain bits in a hypervisor CSR - which would be in effect because of misa.H=1.  If it was just a matter of new hypervisor CSRs and new hypervisor instructions, then things would be OK as long as code didn't try to touch those.

Greg


On Wed, Jun 3, 2020 at 12:05 PM Jonathan Behrens <behrensj@...> wrote:
Why would that be a problem? As long as you don't issue any HS-mode instructions or touch any of the hypervisor CSRs then any code should run the same.

Jonathan

On Wed, Jun 3, 2020 at 2:51 PM Greg Favor <gfavor@...> wrote:
One issue is that the current Privileged spec requires that misa.H is reset to '1' if the Hypervisor extension is implemented.  Unaware boot code will leave that set and then problems will ensue later.

Greg


On Wed, Jun 3, 2020 at 11:46 AM Jonathan Behrens <behrensj@...> wrote:
I would expect the rule be that either the reset state properly initializes all the H-extension CSRs or the boot code. Thus if you want hardware to be backwards compatible with legacy boot code, you just have to make sure the reset state is correct. And if you don't care about backwards compatibility then you have the flexibility to not worry about the reset state and just configure things in the boot code.

Jonathan

On Wed, Jun 3, 2020 at 2:31 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
We have run across the situation of running "legacy" (i.e. current) boot code that naturally is unaware of the possible existence of the Hypervisor extension.  Since, on a platform that does implement the Hypervisor extension, misa.H is required to be reset to '1', there are architectural behavior changes that can trip up this boot code.  Both because the hypervisor extension is enabled and because new CSR's (some of which contain bits that, for example, affect the behavior of existing instructions) will remain uninitialized by this unaware boot code.

We suspect that the following is the view by the architecture:

Boot code that may run on platforms that may or may not support certain arch extensions (such as the Hypervisor extension) must be aware of their potential existence and be prepared to deal with misa indicating that they are or are not supported.

Conversely, unaware "legacy" boot code is not expected or required to run as-is on newer platforms that support newer arch extensions.  Such "old" boot code must be ported to run on platforms that implement new architecture extensions like the Hypervisor extension.  

Yes?

Greg


Re: Boot code awareness of the Hypervisor extension

Jonathan Behrens <behrensj@...>
 

If hstatus.SPV=0, then SRET behaves like normal. And since that bit will stay zero unless some code messes with hypervisor CSRs, it should be sufficient to just have the reset state initialize it that way.

Jonathan


On Wed, Jun 3, 2020 at 3:15 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
But there is existing architecture functionality (e.g. the SRET instruction) that is affected by certain bits in a hypervisor CSR - which would be in effect because of misa.H=1.  If it was just a matter of new hypervisor CSRs and new hypervisor instructions, then things would be OK as long as code didn't try to touch those.

Greg


On Wed, Jun 3, 2020 at 12:05 PM Jonathan Behrens <behrensj@...> wrote:
Why would that be a problem? As long as you don't issue any HS-mode instructions or touch any of the hypervisor CSRs then any code should run the same.

Jonathan

On Wed, Jun 3, 2020 at 2:51 PM Greg Favor <gfavor@...> wrote:
One issue is that the current Privileged spec requires that misa.H is reset to '1' if the Hypervisor extension is implemented.  Unaware boot code will leave that set and then problems will ensue later.

Greg


On Wed, Jun 3, 2020 at 11:46 AM Jonathan Behrens <behrensj@...> wrote:
I would expect the rule be that either the reset state properly initializes all the H-extension CSRs or the boot code. Thus if you want hardware to be backwards compatible with legacy boot code, you just have to make sure the reset state is correct. And if you don't care about backwards compatibility then you have the flexibility to not worry about the reset state and just configure things in the boot code.

Jonathan

On Wed, Jun 3, 2020 at 2:31 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
We have run across the situation of running "legacy" (i.e. current) boot code that naturally is unaware of the possible existence of the Hypervisor extension.  Since, on a platform that does implement the Hypervisor extension, misa.H is required to be reset to '1', there are architectural behavior changes that can trip up this boot code.  Both because the hypervisor extension is enabled and because new CSR's (some of which contain bits that, for example, affect the behavior of existing instructions) will remain uninitialized by this unaware boot code.

We suspect that the following is the view by the architecture:

Boot code that may run on platforms that may or may not support certain arch extensions (such as the Hypervisor extension) must be aware of their potential existence and be prepared to deal with misa indicating that they are or are not supported.

Conversely, unaware "legacy" boot code is not expected or required to run as-is on newer platforms that support newer arch extensions.  Such "old" boot code must be ported to run on platforms that implement new architecture extensions like the Hypervisor extension.  

Yes?

Greg


Re: Boot code awareness of the Hypervisor extension

Greg Favor
 

I agree with this one example.  But I'm also trying to address the broader issue and ask the more general architecture-level question (that I originally stated), i.e. must new implementations that support newer arch extensions be able to run "old" boot code that is unaware of the new extensions and hence makes no effort to disable the next extensions in misa (which, btw, is not guaranteed by the spec to even be possible)?  (And that boot code of course also makes no effort to initialize new CSR's that it is unaware of.)

If the answer is Yes, then the Privileged spec should state this architectural requirement (and each arch extension must make sure that it doesn't define anything in a way that prevents this from being achievable).  If the answer is No, then the spec should state that there is not this requirement.

Greg

On Wed, Jun 3, 2020 at 1:13 PM Jonathan Behrens <behrensj@...> wrote:
If hstatus.SPV=0, then SRET behaves like normal. And since that bit will stay zero unless some code messes with hypervisor CSRs, it should be sufficient to just have the reset state initialize it that way.

Jonathan

On Wed, Jun 3, 2020 at 3:15 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
But there is existing architecture functionality (e.g. the SRET instruction) that is affected by certain bits in a hypervisor CSR - which would be in effect because of misa.H=1.  If it was just a matter of new hypervisor CSRs and new hypervisor instructions, then things would be OK as long as code didn't try to touch those.

Greg


On Wed, Jun 3, 2020 at 12:05 PM Jonathan Behrens <behrensj@...> wrote:
Why would that be a problem? As long as you don't issue any HS-mode instructions or touch any of the hypervisor CSRs then any code should run the same.

Jonathan

On Wed, Jun 3, 2020 at 2:51 PM Greg Favor <gfavor@...> wrote:
One issue is that the current Privileged spec requires that misa.H is reset to '1' if the Hypervisor extension is implemented.  Unaware boot code will leave that set and then problems will ensue later.

Greg


On Wed, Jun 3, 2020 at 11:46 AM Jonathan Behrens <behrensj@...> wrote:
I would expect the rule be that either the reset state properly initializes all the H-extension CSRs or the boot code. Thus if you want hardware to be backwards compatible with legacy boot code, you just have to make sure the reset state is correct. And if you don't care about backwards compatibility then you have the flexibility to not worry about the reset state and just configure things in the boot code.

Jonathan

On Wed, Jun 3, 2020 at 2:31 PM Greg Favor via lists.riscv.org <gfavor=ventanamicro.com@...> wrote:
We have run across the situation of running "legacy" (i.e. current) boot code that naturally is unaware of the possible existence of the Hypervisor extension.  Since, on a platform that does implement the Hypervisor extension, misa.H is required to be reset to '1', there are architectural behavior changes that can trip up this boot code.  Both because the hypervisor extension is enabled and because new CSR's (some of which contain bits that, for example, affect the behavior of existing instructions) will remain uninitialized by this unaware boot code.

We suspect that the following is the view by the architecture:

Boot code that may run on platforms that may or may not support certain arch extensions (such as the Hypervisor extension) must be aware of their potential existence and be prepared to deal with misa indicating that they are or are not supported.

Conversely, unaware "legacy" boot code is not expected or required to run as-is on newer platforms that support newer arch extensions.  Such "old" boot code must be ported to run on platforms that implement new architecture extensions like the Hypervisor extension.  

Yes?

Greg


Address Mapping Questions

Nagendra Gulur
 

Dear team,

This may be a basic question: I am trying to figure out where in the physical memory map are the "mtime" and "mtimecmp" registers to be placed.
Per the privileged spec, these registers are memory-mapped, but I could not find an address specification for these registers. Did I somehow miss finding this piece of information from the spec or is it actually not specified? If the latter, is there a different place where it is specified that an implementation should comply with?

Another question: are CSRs also memory mapped? In debug mode?

Thank you and apologies if these questions have been discussed and resolved before.

Best Regards
Nagendra


 


Re: Address Mapping Questions

Andrew Waterman
 

The memory map isn't in the spec because it's platform-defined.  Some folks use the SiFive CLINT as a de facto standard for the address map for mtime[cmp] and MSIP registers.  QEMU supports this as well.  You can find the CLINT memory map in Chapter 8 of https://sifive.cdn.prismic.io/sifive/86e05812-e9cd-4553-bfef-c7e715088055_sifive_coreip_U54MC_AXI4_rtl_v19_08p2p0_release_manual.pdf


On Thu, Jun 4, 2020 at 5:34 PM Nagendra Gulur <nagendra.gd@...> wrote:
Dear team,

This may be a basic question: I am trying to figure out where in the physical memory map are the "mtime" and "mtimecmp" registers to be placed.
Per the privileged spec, these registers are memory-mapped, but I could not find an address specification for these registers. Did I somehow miss finding this piece of information from the spec or is it actually not specified? If the latter, is there a different place where it is specified that an implementation should comply with?

Another question: are CSRs also memory mapped? In debug mode?

Thank you and apologies if these questions have been discussed and resolved before.

Best Regards
Nagendra


 


Re: Address Mapping Questions

Nagendra Gulur
 

Thanks Andrew - yes this de facto is great information. Is there any platform-level effort to convert this to a standard? 

Best Regards
Nagendra


On Thu, Jun 4, 2020 at 8:01 PM Andrew Waterman <andrew@...> wrote:
The memory map isn't in the spec because it's platform-defined.  Some folks use the SiFive CLINT as a de facto standard for the address map for mtime[cmp] and MSIP registers.  QEMU supports this as well.  You can find the CLINT memory map in Chapter 8 of https://sifive.cdn.prismic.io/sifive/86e05812-e9cd-4553-bfef-c7e715088055_sifive_coreip_U54MC_AXI4_rtl_v19_08p2p0_release_manual.pdf

On Thu, Jun 4, 2020 at 5:34 PM Nagendra Gulur <nagendra.gd@...> wrote:
Dear team,

This may be a basic question: I am trying to figure out where in the physical memory map are the "mtime" and "mtimecmp" registers to be placed.
Per the privileged spec, these registers are memory-mapped, but I could not find an address specification for these registers. Did I somehow miss finding this piece of information from the spec or is it actually not specified? If the latter, is there a different place where it is specified that an implementation should comply with?

Another question: are CSRs also memory mapped? In debug mode?

Thank you and apologies if these questions have been discussed and resolved before.

Best Regards
Nagendra


 


Re: Address Mapping Questions

Andrew Waterman
 

It's something that could conceivably be standardized by the Unix platform task group, but I'm unaware as to whether that's in their plan of record.


On Thu, Jun 4, 2020 at 6:46 PM Nagendra Gd <nagendra.gd@...> wrote:
Thanks Andrew - yes this de facto is great information. Is there any platform-level effort to convert this to a standard? 

Best Regards
Nagendra


On Thu, Jun 4, 2020 at 8:01 PM Andrew Waterman <andrew@...> wrote:
The memory map isn't in the spec because it's platform-defined.  Some folks use the SiFive CLINT as a de facto standard for the address map for mtime[cmp] and MSIP registers.  QEMU supports this as well.  You can find the CLINT memory map in Chapter 8 of https://sifive.cdn.prismic.io/sifive/86e05812-e9cd-4553-bfef-c7e715088055_sifive_coreip_U54MC_AXI4_rtl_v19_08p2p0_release_manual.pdf

On Thu, Jun 4, 2020 at 5:34 PM Nagendra Gulur <nagendra.gd@...> wrote:
Dear team,

This may be a basic question: I am trying to figure out where in the physical memory map are the "mtime" and "mtimecmp" registers to be placed.
Per the privileged spec, these registers are memory-mapped, but I could not find an address specification for these registers. Did I somehow miss finding this piece of information from the spec or is it actually not specified? If the latter, is there a different place where it is specified that an implementation should comply with?

Another question: are CSRs also memory mapped? In debug mode?

Thank you and apologies if these questions have been discussed and resolved before.

Best Regards
Nagendra


 


Re: Address Mapping Questions

Nikhil Rishiyur
 

In re. your other question:

>    Another question: are CSRs also memory mapped? In debug mode?

No, CSRs are not specified as memory-mapped (an implementation may
choose to do so), even in Debug Mode.

The Debug Module (not the CPU) has an 'Access Register' abstract
command (see Sec. 3.6.1 "Access Register" section of the Debug Module
Spec) where it uses an Abstract Register Number to name all GPRs, FPRs
and CSRs (see Table 3.3 in the Debug Spec). 0x0000-0x0FFF are used for
CSRs, 0x1000-0x101F for GPRs, and 0x1020-103F for FPRs.  This is not a
'memory-mapping' of CSRs, just the internal Debug Module (and GDB's)
convention on how to name all registers.

Best regards,

Nikhil


Re: Address Mapping Questions

Allen Baum
 

A bit more on that.
There are a few debug CSRs which can be accessed as both CSRs and as Debug registers, specifically for communication.
Otherwise, debug registers are in their own address space, and accessible only through the debug module.

As Nikhil says, there is also a command to enable access to all CSRs through the debug module by writing specific debug command register (Abstract Command)  which will cause the value of a CSR to be read from/written to a communication debug register  (Data0 and possibly Data1) .


On Fri, Jun 5, 2020 at 5:15 AM Nikhil Rishiyur <nikhil@...> wrote:
In re. your other question:

>    Another question: are CSRs also memory mapped? In debug mode?

No, CSRs are not specified as memory-mapped (an implementation may
choose to do so), even in Debug Mode.

The Debug Module (not the CPU) has an 'Access Register' abstract
command (see Sec. 3.6.1 "Access Register" section of the Debug Module
Spec) where it uses an Abstract Register Number to name all GPRs, FPRs
and CSRs (see Table 3.3 in the Debug Spec). 0x0000-0x0FFF are used for
CSRs, 0x1000-0x101F for GPRs, and 0x1020-103F for FPRs.  This is not a
'memory-mapping' of CSRs, just the internal Debug Module (and GDB's)
convention on how to name all registers.

Best regards,

Nikhil


Re: Boot code awareness of the Hypervisor extension

Greg Favor
 

Can someone provide a definitive answer (Andrew?) as to the architectural intent of whether implementations supporting new architecture extensions must maintain backward compatibility with "legacy" M mode software (and User/Supervisor software running under that M-mode software) that is unaware of the extensions yet the extensions are left enabled?  (This becomes more relevant as standard M-mode reference boot software and commercial TEE software products become established in the RISC-V Linux world.)

'No' says that it is alright to presume or require use of non-legacy M-mode boot software (or modifications to that software) that will disable the relevant misa bits if necessary.  This hopefully is the answer.

'Yes' says that the implementation must reset further architectural state past what is defined in the Privileged spec so as to ensure well-behaved Supervisor code, and somewhat well-behaved User code, isn't affected by the unexpected yet enabled extensions. In the case of the Hypervisor extension, for example, three bits of CSR state must reset to specific values.  And future extensions must have this characteristic that there does exist a set of fixed reset values to accomplish this.  (If 'Yes', then it might be useful for the Hypervisor spec to specify what additional hart reset state is necessary to satisfy this architectural intent/requirement.)

Greg


Re: Boot code awareness of the Hypervisor extension

Andrew Waterman
 



On Mon, Jun 8, 2020 at 6:18 PM Greg Favor <gfavor@...> wrote:
Can someone provide a definitive answer (Andrew?) as to the architectural intent of whether implementations supporting new architecture extensions must maintain backward compatibility with "legacy" M mode software (and User/Supervisor software running under that M-mode software) that is unaware of the extensions yet the extensions are left enabled?  (This becomes more relevant as standard M-mode reference boot software and commercial TEE software products become established in the RISC-V Linux world.)

It certainly has been a goal, e.g., the CLIC was designed so that M-mode software that's oblivious to the CLIC still runs correctly on systems with the CLIC.

I don't think there's a clear statement of principle on the matter, so it is something for us to decide as a group.  In this particular case, if we can maintain compatibility with existing M-mode software by only resetting a few state bits, then I think we should reset a few state bits.


'No' says that it is alright to presume or require use of non-legacy M-mode boot software (or modifications to that software) that will disable the relevant misa bits if necessary.  This hopefully is the answer.

'Yes' says that the implementation must reset further architectural state past what is defined in the Privileged spec so as to ensure well-behaved Supervisor code, and somewhat well-behaved User code, isn't affected by the unexpected yet enabled extensions. In the case of the Hypervisor extension, for example, three bits of CSR state must reset to specific values.  And future extensions must have this characteristic that there does exist a set of fixed reset values to accomplish this.  (If 'Yes', then it might be useful for the Hypervisor spec to specify what additional hart reset state is necessary to satisfy this architectural intent/requirement.)

Agreed, if we go this route, the hypervisor spec needs to clearly state which things need to be reset.
 

Greg

141 - 160 of 1210