1. Messages
  2. Boot code awareness of the Hypervisor extension

Re: Boot code awareness of the Hypervisor extension

Greg Favor
 

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.)
Join {tech-privileged@lists.riscv.org to automatically receive all group messages.