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
|
