Privileged Architecture

Bit L (11) of misa indicates that the KLE extension is present; if KLE is implemented, it must not be read-only zero.

M-mode firmware that provides an emulated KLE unit may set this bit to 1. It must not clear misa.L without first zeroizing all KLE state, emulated or in hardware (kl.clearall and the CSRs of KLE Unprivileged State out of Reset); while misa.L is clear, the KLE state is inaccessible, and need not be retained.

mklvendorid, mklarchid and mklimpid identify the version of the KLE unit, as mvendorid, marchid and mimpid do for the hart. They are part of Zkl common. Their values out of KLE unit reset identify the KLE unit. Where M-mode software emulates the unit, in whole or in part, it keeps the IMPQUAL it uses in its own memory, or takes it from these CSRs of the hardware part; no other mode reads it. They are read-only and M-mode-only: a write in any mode, and any access from a lower mode, raises an illegal-instruction exception, or the virtual-instruction exception of the H extension where it prescribes one.

On RV64, a read of any of these three CSRs returns its 32-bit value zero-extended to XLEN.

Together, the values of these three CSRs form the Implementation Qualifier (AuxDataLen and ADSDropped Fields).

mstatus[26:25] holds a KLE context status field, KLS, shadowed in sstatus[26:25]. Defined like the floating-point and vector context status fields FS and VS, it tracks the dirtiness of the lockers, the KLIOBUF and every writable KLE-specific CSR other than the mklcsk group. mstatus.KLS is always in effect; when V=1, the vsstatus.KLS field of KLE Context Status in vsstatus is also in effect.

The following holds for every KLS field, in the privilege modes in which it is in effect:

A hart that implements the KLE Privileged Architecture implements the KLS field in every *status register it implements. The field is present and writable while misa.L is clear, like FS and VS; an emulated KLE unit relies on this.

A write to a KLS field modifies no KLE state: setting the field to Off, Initial or Clean does not clear the lockers, the KLIOBUF or the KLE CSRs, so any such state change must be explicit, and must precede the write.

mstatus[27] holds kleemulation, a bit M-mode sets when it emulates Machines the KLE unit does not implement natively. It is not visible in sstatus or vsstatus, and it resets to 0. M-mode that sets kleemulation keeps medeleg bit 2 zero, so the exception reaches it, as for trap-and-emulate (Extensions Overview), and forwards any other illegal-instruction exception in software. It controls the Forms B and C of kl.avail and kl.size, which take an MDH supplied in registers rather than a locker (kl.avail and kl.size), once they reach the lookup of item 5 of kl.size; the earlier items, among them the 16 that kl.size returns for an MDH in an Error State, do not depend on which Machines are implemented:

With the H extension, vsstatus[26:25] also holds a KLS field. When V=1, it is in effect together with mstatus.KLS, and KLE Context Status in mstatus and sstatus governs both.

The 64-bit registers mllockerstatus, sllockerstatus, and vsllockerstatus track per-locker status, including dirtiness, at all levels below M-mode, S-mode, and VS-mode, respectively.

The *llockerstatus fields that an instruction sets to Dirty are those in effect, that is, those owned by the privilege modes above the one in which it executes; an instruction never writes the field owned by its own mode.

The KLE locker-Off exception is a single exception cause, whichever *llockerstatus field is Off, and medeleg and hedeleg delegate it as any other cause. While any of its own fields is Off, a mode keeps the cause undelegated, in medeleg if it is M-mode or in hedeleg if it is HS-mode. The handler that takes the exception examines the fields in effect, in the order mllockerstatus, sllockerstatus, vsllockerstatus, starting from the field owned by its own mode. If its own field (i) is Off, it resolves the condition itself, and otherwise forwards the exception to the most privileged mode whose field is Off, which owns that field and can write it. A handler never services a KLE locker-Off exception for a field it cannot write. The instructions that it issues to resolve the condition remain subject to the fields of more privileged modes; a KLE locker-Off exception that one of them raises, as for a locker that M-mode emulates, is taken by the mode that owns that field.

The optional mklcsk group consists of the four MXLEN-bit M-mode RW CSRs mklcsk0 to mklcsk3 and, when MXLEN = 32, of their shadows mklcsk0h to mklcsk3h.

A write to `mklcsk`i supplies bits [64·i+MXLEN−1 : 64·i], and a write to `mklcsk`ih bits [64·i+63 : 64·i+32], of the value that becomes the CSK once the group has been written in full.

This CSR group is accessible in M-mode whenever KLS is not Off and misa.L is set; any other access raises an illegal-instruction exception. An access in Debug mode that the External Debug Security extension does not authorize for M-mode raises an illegal-instruction exception. Out of reset KLS is Off (KLE Privileged State out of Reset); M-mode firmware enables KLS before it establishes the CSK.

A new CSK becomes active only once every CSR of the group has been written since the previous activation; from the first such write until then, the CSK is partially written, and the KLE unit is unavailable (KLE missing-CSK exception, Architectural Requirements on the Context Sealing Key).

Reading a register of the group returns the corresponding part of the active CSK; while no CSK is active (none established, or partially written), the read raises the KLE missing-CSK exception.

A write to the group is not checked against the state of the lockers, configured or under management included: M-mode must write it only after saving all KLE state that it must preserve.

A CSK whose value is zeros(256) is unconfigured in each of the four ways of Architectural Requirements on the Context Sealing Key: writing that value in full through the mklcsk group discards any established CSK and leaves the unit without a CSK; and whenever a CSK is randomly generated, as under the fourth way, an all-zero output of the RBG is discarded and regenerated.

The KLE unit is unavailable until a CSK is established (Architectural Requirements on the Context Sealing Key): at once for a hardwired CSK, and as soon as it has been generated for a boot-generated one.

mklmaxiobuflen is an MXLEN-bit M-mode CSR, present with Zklio only, that holds the maximum configurable length of the KLIOBUF, in bytes; its hardwired value out of KLE unit reset is its maximum. Software in the other modes has no access to it: as with vsetvl, it learns the maximum by writing a larger value to kliobuflen and reading it back. M-mode should write it only while the KLE unit is in its state out of reset (KLE Unprivileged State out of Reset), before any write to kliobuflen, and should never reduce it below the current kliobuflen: after a write that does, kliobuflen and kliobuftop become 0 and the whole KLIOBUF is zeroized; no other state is affected.

A write to mklmaxiobuflen is WARL: a value above its value out of KLE unit reset sets that value, and a value below the lower bound sets that lower bound. The lower bound is the larger of 16 bytes and the largest basic processing unit (granularity) of any implemented Machine.

Each group listed in Table 7 holds one 128-bit Locality Secret (Architected Localities. Bits refer to the Locality field in the MDH.) in two RW CSRs, numbered “0” and “1”, of W bits, where W is MXLEN for an M-mode group and SXLEN for an HS-mode or S-mode group, and, when W = 32, in their shadows, numbered “0h” and “1h”. A write to CSR i of a group sets bits [64·i+W−1 : 64·i] of its secret, and a write to CSR ih bits [64·i+63 : 64·i+32]. An access below the privilege of the group raises the exception that CSRs prescribes; an access in Debug mode that the External Debug Security extension does not authorize for the privilege of the group raises an illegal-instruction exception. The groups are accessible whether or not a CSK has been established (Architectural Requirements on the Context Sealing Key): no ordering between CSK and Locality configuration is enforced.

Software that exports lockers on behalf of a lower privilege level configures every SW Filter Group register it owns before doing so: the export of a locker whose Locality names an unconfigured entry is refused (Generation of an SCC from a Fully Configured Locker). The hypervisor’s duty to clear hkllocality and hklvirtbootscrt before running such software is Rule SR13.

The Locality CSR groups are readable at their respective privilege levels, and context-switch software saves and restores them like any other CSR.