|
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
|
|
|
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
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
|
|
|
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
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
|
|
|
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
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
|
|
|
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
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
|
|
|
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
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
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
|
|
|
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
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
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
|
|
|
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
|
|
|
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.
|
|
|
I want to bring back up the Yes/No question I posed a couple of weeks ago - in which I was looking for a clear architectural statement of principle as to whether:
A) A new architecture extension must maintain backward compatibility with unaware M, S, and U mode software while the extension is left enabled. This tends to require additional resetting of key architectural state to achieve this - that (as Andrew agreed) should be specified in the extension's arch spec. (In the case of the Hypervisor extension, for example, three bits of CSR state must be reset to specific values to provide backward compatibility for well-behaved M/S/U code.)
OR
B) It is alright to presume or require use of extension-aware M-mode boot software that will disable the relevant misa bits as necessary (at which point there is no need for architectural specification of reset state to ensure backward compatibility, nor any need to worry about this).
Greg
On Mon, Jun 8, 2020 at 6:25 PM Andrew Waterman < andrew@...> wrote: 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.)
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.
|
|
|
Anup Patel
The M-mode runtime firmware cannot be totally unaware of new extensions. At least, this is true for H-extension.
Currently M-mode runtime firmware (OpenSBI) does following to support H-extension:
- Emulate misaligned load-store for VS/VU mode using unprivileged access
- Emulate HTIMEDELTA CSR when underlying hardware does not implement it
- Redirect unhandled illegal instruction traps from VS/VU mode to HS-mode
For V-extension, the M-mode runtime firmware will have to emulate misaligned load-store for V-extension related load/store instructions.
Regards,
Anup
toggle quoted message
Show quoted text
From: tech-privileged@... <tech-privileged@...>
On Behalf Of Greg Favor
Sent: 23 June 2020 10:54
To: Andrew Waterman <andrew@...>; tech-privileged@...
Cc: Greg Favor <gfavor@...>
Subject: Re: [RISC-V] [tech-privileged] Boot code awareness of the Hypervisor extension
I want to bring back up the Yes/No question I posed a couple of weeks ago - in which I was looking for a clear architectural statement of principle as to whether:
A) A new architecture extension must maintain backward compatibility with unaware M, S, and U mode software while the extension is left
enabled. This tends to require additional resetting of key architectural state to achieve this - that (as Andrew agreed) should be specified in the extension's arch spec. (In the case of the Hypervisor extension, for example, three bits of CSR state
must be reset to specific values to provide backward compatibility for well-behaved M/S/U code.)
B) It is alright to presume or require use of extension-aware M-mode boot software that will disable the relevant misa bits as necessary (at which point there is no need for architectural specification of reset state to ensure backward
compatibility, nor any need to worry about this).
Greg
On Mon, Jun 8, 2020 at 6:25 PM Andrew Waterman <andrew@...> wrote:
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.)
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.
|
|
|
mark
how is this intended to work with versions?
so we ratify some 1.0 spec and we come along and call it 1.1 that has additive changes, i thought i heard that ecosystem around risc-v including compilers and operating systems and boot loaders, etc must support all valid versions or we will orphan released hw that is based on the previous version of the spec. we had this discussion around bitmanip and I think (if i understood krste correctly) we should make sure all versions of the isa are supported by the ecosystem.
am i missing something?
thanks mark
On Mon, Jun 22, 2020 at 10:24 PM Greg Favor < gfavor@...> wrote: I want to bring back up the Yes/No question I posed a couple of weeks ago - in which I was looking for a clear architectural statement of principle as to whether:
A) A new architecture extension must maintain backward compatibility with unaware M, S, and U mode software while the extension is left enabled. This tends to require additional resetting of key architectural state to achieve this - that (as Andrew agreed) should be specified in the extension's arch spec. (In the case of the Hypervisor extension, for example, three bits of CSR state must be reset to specific values to provide backward compatibility for well-behaved M/S/U code.)
OR
B) It is alright to presume or require use of extension-aware M-mode boot software that will disable the relevant misa bits as necessary (at which point there is no need for architectural specification of reset state to ensure backward compatibility, nor any need to worry about this).
Greg On Mon, Jun 8, 2020 at 6:25 PM Andrew Waterman < andrew@...> wrote: 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.)
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.
-- Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv
|
|
|
Mark,
Hi and welcome on board the RISC-V train. I agree with the general broad issue of ecosystem compatibility and support. The much narrower current question is whether the issue I'm touching on is a burden placed solely on hardware (and associated specification by arch extension specs), or can M-mode boot firmware be looked to for properly disabling extensions that the system software being loaded is not aware of and is not prepared for those to be present and enabled.
One key point you probably aren't aware of is that the Privileged spec requires that all extensions (in the misa CSR) are initialized by reset to "enabled". This means that M-mode boot software that is unaware of new extensions (e.g. the Hypervisor extension) will not know to enable/disable them appropriately (thus unintentionally leaving them enabled). And unless hardware reset also initializes certain extension-related architectural state (that properly should be specified by architecture specs), that unaware software may encounter unexpected behavior of existing instructions and other
existing
arch functionality.
So either there needs to be an architectural requirement that hardware reset must initialize more architectural state than is currently specified in the Priv spec, or there is explicit architectural allowance for having M-mode boot software that is aware of the extensions that may (or may not) be supported by the hardware it is running on (and will disable new extensions as is appropriate).
Note that extensions like bitmanip - that only add new instructions and don't modify any existing CSRs or instructions - aren't an issue. But extensions like the Hypervisor extension are an issue. Without M-mode boot software disabling the
Hypervisor
extension, hardware instead must reset-initialize three specific architectural state bits to keep unaware but well-behaved software out of trouble. (To avoid not so well-behaved software from being affected, requires having M-mode software actually disable the extension.)
Greg
how is this intended to work with versions?
so we ratify some 1.0 spec and we come along and call it 1.1 that has additive changes, i thought i heard that ecosystem around risc-v including compilers and operating systems and boot loaders, etc must support all valid versions or we will orphan released hw that is based on the previous version of the spec. we had this discussion around bitmanip and I think (if i understood krste correctly) we should make sure all versions of the isa are supported by the ecosystem.
am i missing something?
thanks mark On Mon, Jun 22, 2020 at 10:24 PM Greg Favor < gfavor@...> wrote: I want to bring back up the Yes/No question I posed a couple of weeks ago - in which I was looking for a clear architectural statement of principle as to whether:
A) A new architecture extension must maintain backward compatibility with unaware M, S, and U mode software while the extension is left enabled. This tends to require additional resetting of key architectural state to achieve this - that (as Andrew agreed) should be specified in the extension's arch spec. (In the case of the Hypervisor extension, for example, three bits of CSR state must be reset to specific values to provide backward compatibility for well-behaved M/S/U code.)
OR
B) It is alright to presume or require use of extension-aware M-mode boot software that will disable the relevant misa bits as necessary (at which point there is no need for architectural specification of reset state to ensure backward compatibility, nor any need to worry about this).
Greg On Mon, Jun 8, 2020 at 6:25 PM Andrew Waterman < andrew@...> wrote: 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.)
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.
Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv
|
|
|
This would seem to argue for answer "B" to my question.
I find this preferable since it doesn't require architecture extension spec's to specify additional arch state that must be initialized by hart reset to specific values.
Greg
The M-mode runtime firmware cannot be totally unaware of new extensions. At least, this is true for H-extension.
Currently M-mode runtime firmware (OpenSBI) does following to support H-extension:
- Emulate misaligned load-store for VS/VU mode using unprivileged access
- Emulate HTIMEDELTA CSR when underlying hardware does not implement it
- Redirect unhandled illegal instruction traps from VS/VU mode to HS-mode
For V-extension, the M-mode runtime firmware will have to emulate misaligned load-store for V-extension related load/store instructions.
Regards,
Anup
I want to bring back up the Yes/No question I posed a couple of weeks ago - in which I was looking for a clear architectural statement of principle as to whether:
A) A new architecture extension must maintain backward compatibility with unaware M, S, and U mode software while the extension is left
enabled. This tends to require additional resetting of key architectural state to achieve this - that (as Andrew agreed) should be specified in the extension's arch spec. (In the case of the Hypervisor extension, for example, three bits of CSR state
must be reset to specific values to provide backward compatibility for well-behaved M/S/U code.)
B) It is alright to presume or require use of extension-aware M-mode boot software that will disable the relevant misa bits as necessary (at which point there is no need for architectural specification of reset state to ensure backward
compatibility, nor any need to worry about this).
Greg
On Mon, Jun 8, 2020 at 6:25 PM Andrew Waterman <andrew@...> wrote:
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.)
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.
|
|
|
On Tue, Jun 23, 2020 at 12:40 PM Greg Favor < gfavor@...> wrote: This would seem to argue for answer "B" to my question.
FWIW, I think supervisor mode already follows answer "B", inasmuch as the satp and medeleg registers are not reset. Consider M-mode software written to run on a system with only M and U modes, but executed on a system with M/S/U. The software might not zero medeleg/mideleg, meaning a trap in U-mode might unintentionally transfer control to S-mode; or it might not zero satp, meaning paging might inadvertently be enabled while executing in U-mode.
(It's of course possible to write this software to work on either an M/U or an M/S/U system, but it takes extra care to check for the presence of S-mode and conditionally initialize the relevant state.)
I find this preferable since it doesn't require architecture extension spec's to specify additional arch state that must be initialized by hart reset to specific values.
Greg
The M-mode runtime firmware cannot be totally unaware of new extensions. At least, this is true for H-extension.
Currently M-mode runtime firmware (OpenSBI) does following to support H-extension:
- Emulate misaligned load-store for VS/VU mode using unprivileged access
- Emulate HTIMEDELTA CSR when underlying hardware does not implement it
- Redirect unhandled illegal instruction traps from VS/VU mode to HS-mode
For V-extension, the M-mode runtime firmware will have to emulate misaligned load-store for V-extension related load/store instructions.
Regards,
Anup
I want to bring back up the Yes/No question I posed a couple of weeks ago - in which I was looking for a clear architectural statement of principle as to whether:
A) A new architecture extension must maintain backward compatibility with unaware M, S, and U mode software while the extension is left
enabled. This tends to require additional resetting of key architectural state to achieve this - that (as Andrew agreed) should be specified in the extension's arch spec. (In the case of the Hypervisor extension, for example, three bits of CSR state
must be reset to specific values to provide backward compatibility for well-behaved M/S/U code.)
B) It is alright to presume or require use of extension-aware M-mode boot software that will disable the relevant misa bits as necessary (at which point there is no need for architectural specification of reset state to ensure backward
compatibility, nor any need to worry about this).
Greg
On Mon, Jun 8, 2020 at 6:25 PM Andrew Waterman <andrew@...> wrote:
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.)
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.
|
|
|
mark
Thank you.
If I understand this correctly I agree with all you have said. If this is a once at boot time requirement regardless of mode and there is a reasonable way to do it, then i concur that well documented guidance should be sufficient and i, like others in this email chain, prefer adding sw requirements over isa requirements where appropriate.
As a more generalized discussion that likely needs to be carried on at tsc or chairs, I have begun discussing with people including Krste as to whether we can develop a list of questions to be able to understand any change/addition proposed to the isa in a similar way (not criteria but more like common analysis) and cause the questions to always be answered up front and not have to be remembered as things we need to bring up.
Because of this discussion I would advocate adding a question to the list like "is this done once or rarely and if so could it be handled in sw without other significant impact?" (other questions might include what is the performance impact, or functionality gaps filled like the vector spec, or attributes like plugging security holes, impact of implementing the proposal with existing instructions etc.)
I don't want to burden this email chain with the generalized discussion and we will likely start a thread on this soon but wanted you all to know how important this discussion was and hope we can learn from and integrate the philosophies discussed below into future conversations.
Mark
On Tue, Jun 23, 2020 at 2:22 PM Andrew Waterman < andrew@...> wrote:
On Tue, Jun 23, 2020 at 12:40 PM Greg Favor < gfavor@...> wrote: This would seem to argue for answer "B" to my question.
FWIW, I think supervisor mode already follows answer "B", inasmuch as the satp and medeleg registers are not reset. Consider M-mode software written to run on a system with only M and U modes, but executed on a system with M/S/U. The software might not zero medeleg/mideleg, meaning a trap in U-mode might unintentionally transfer control to S-mode; or it might not zero satp, meaning paging might inadvertently be enabled while executing in U-mode.
(It's of course possible to write this software to work on either an M/U or an M/S/U system, but it takes extra care to check for the presence of S-mode and conditionally initialize the relevant state.)
I find this preferable since it doesn't require architecture extension spec's to specify additional arch state that must be initialized by hart reset to specific values.
Greg
The M-mode runtime firmware cannot be totally unaware of new extensions. At least, this is true for H-extension.
Currently M-mode runtime firmware (OpenSBI) does following to support H-extension:
- Emulate misaligned load-store for VS/VU mode using unprivileged access
- Emulate HTIMEDELTA CSR when underlying hardware does not implement it
- Redirect unhandled illegal instruction traps from VS/VU mode to HS-mode
For V-extension, the M-mode runtime firmware will have to emulate misaligned load-store for V-extension related load/store instructions.
Regards,
Anup
I want to bring back up the Yes/No question I posed a couple of weeks ago - in which I was looking for a clear architectural statement of principle as to whether:
A) A new architecture extension must maintain backward compatibility with unaware M, S, and U mode software while the extension is left
enabled. This tends to require additional resetting of key architectural state to achieve this - that (as Andrew agreed) should be specified in the extension's arch spec. (In the case of the Hypervisor extension, for example, three bits of CSR state
must be reset to specific values to provide backward compatibility for well-behaved M/S/U code.)
B) It is alright to presume or require use of extension-aware M-mode boot software that will disable the relevant misa bits as necessary (at which point there is no need for architectural specification of reset state to ensure backward
compatibility, nor any need to worry about this).
Greg
On Mon, Jun 8, 2020 at 6:25 PM Andrew Waterman <andrew@...> wrote:
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.)
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.
-- Mark I Himelstein
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv
|
|
|
This seems like a fairly big nail in the coffin for answer "A". And responses by others (e.g. Anup and Mark) also fall on the side of answer "B".
Are we at a point to call the ball, i.e. adopt answer "B" and add something to the Privileged spec accordingly?
If so, that might be along the lines of saying that an implementation that supports a new architecture extension is not required to be able to run "old/legacy" M-mode boot software that is unaware of the possible existence of that extension, and
is not required
to then run all other extension-unaware system and user software as expected while the extension remains enabled. Conversely it would be the M-mode boot software's responsibility to properly either disable a new extension, or initialize the extension's relevant architectural state so that other (well-behaved) extension-unaware system and user software can run as expected.
Greg
On Tue, Jun 23, 2020 at 2:22 PM Andrew Waterman < andrew@...> wrote:
On Tue, Jun 23, 2020 at 12:40 PM Greg Favor < gfavor@...> wrote: This would seem to argue for answer "B" to my question.
FWIW, I think supervisor mode already follows answer "B", inasmuch as the satp and medeleg registers are not reset. Consider M-mode software written to run on a system with only M and U modes, but executed on a system with M/S/U. The software might not zero medeleg/mideleg, meaning a trap in U-mode might unintentionally transfer control to S-mode; or it might not zero satp, meaning paging might inadvertently be enabled while executing in U-mode.
(It's of course possible to write this software to work on either an M/U or an M/S/U system, but it takes extra care to check for the presence of S-mode and conditionally initialize the relevant state.)
|
|
|
On Wed, Jun 24, 2020 at 11:32 AM Greg Favor < gfavor@...> wrote: This seems like a fairly big nail in the coffin for answer "A". And responses by others (e.g. Anup and Mark) also fall on the side of answer "B".
Are we at a point to call the ball, i.e. adopt answer "B" and add something to the Privileged spec accordingly?
If so, that might be along the lines of saying that an implementation that supports a new architecture extension is not required to be able to run "old/legacy" M-mode boot software that is unaware of the possible existence of that extension, and
is not required
to then run all other extension-unaware system and user software as expected while the extension remains enabled. Conversely it would be the M-mode boot software's responsibility to properly either disable a new extension, or initialize the extension's relevant architectural state so that other (well-behaved) extension-unaware system and user software can run as expected.
I think it's the kind of thing that belongs in the FAQ that Mark mentioned in his previous email.
Greg On Tue, Jun 23, 2020 at 2:22 PM Andrew Waterman < andrew@...> wrote:
On Tue, Jun 23, 2020 at 12:40 PM Greg Favor < gfavor@...> wrote: This would seem to argue for answer "B" to my question.
FWIW, I think supervisor mode already follows answer "B", inasmuch as the satp and medeleg registers are not reset. Consider M-mode software written to run on a system with only M and U modes, but executed on a system with M/S/U. The software might not zero medeleg/mideleg, meaning a trap in U-mode might unintentionally transfer control to S-mode; or it might not zero satp, meaning paging might inadvertently be enabled while executing in U-mode.
(It's of course possible to write this software to work on either an M/U or an M/S/U system, but it takes extra care to check for the presence of S-mode and conditionally initialize the relevant state.)
|
|
|
On Wed, Jun 24, 2020 at 1:36 PM Andrew Waterman < andrew@...> wrote: If so, that might be along the lines of saying that an implementation that supports a new architecture extension is not required to be able to run "old/legacy" M-mode boot software that is unaware of the possible existence of that extension, and
is not required
to then run all other extension-unaware system and user software as expected while the extension remains enabled. Conversely it would be the M-mode boot software's responsibility to properly either disable a new extension, or initialize the extension's relevant architectural state so that other (well-behaved) extension-unaware system and user software can run as expected.
I think it's the kind of thing that belongs in the FAQ that Mark mentioned in his previous email.
It seems like Mark's FAQ suggestion was more general and different from his specific "well documented guidance" comment on this particular issue. To me this particular guidance would belong in the Priv spec so as to make it clear that there is not a hardware requirement to be able to run "old" extension-unaware software all the way from boot onwards. But I'll leave it to you to judge where this best belongs.
Thanks, Greg
|
|
|
