- Boot code awareness of the Hypervisor extension
Re: Boot code awareness of the Hypervisor extension
toggle quoted messageShow quoted text
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.
On Wed, Jun 3, 2020 at 1:13 PM 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.
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
instructions, then things would be OK as long as code didn't try to touch those.
On Wed, Jun 3, 2020 at 12:05 PM 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.
On Wed, Jun 3, 2020 at 2:51 PM Greg Favor <gfavor@...
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.
On Wed, Jun 3, 2020 at 11:46 AM 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.
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.
Join firstname.lastname@example.org to automatically receive all group messages.