Boot code awareness of the Hypervisor extension
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 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.JonathanWe 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.GregOn 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.JonathanWe 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
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.JonathanOn 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.GregOn 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.JonathanWe 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.GregOn 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.JonathanOn 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.GregOn 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.JonathanWe 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
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.JonathanBut 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.GregOn 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.JonathanOn 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.GregOn 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.JonathanWe 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.)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.
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
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.)
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.
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.)ORB) 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).GregOn 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.
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv
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?thanksmark--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.)ORB) 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).GregOn 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
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
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.)
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.
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.
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.GregOn Mon, Jun 22, 2020 at 10:30 PM Anup Patel <Anup.Patel@...> wrote: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
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.)
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.
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.GregOn Mon, Jun 22, 2020 at 10:30 PM Anup Patel <Anup.Patel@...> wrote: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
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.)
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.
CTO RISC-V International
+1-408-250-6611
twitter @mark_riscv
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.)
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.
GregOn 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.)
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.