Re: Fast-track extension proposal for H/W PTE A/D updating

John Ingalls

For visibility: I opened a few issues in the GitHub repository.

On Thu, Oct 27, 2022 at 11:06 AM Allen Baum <allen.baum@...> wrote:
This is more than just clarifying and naming. It also defines a specfic WARL control bit. in an existing, defined CSR.
Individual WARL CSR bits can be RW, RdOnlyZero, or RdOnly1 (WARL *fields* can have infinitely more complex behaviors).
In the discussion, I believe it was also stated that RdOnly 1 was disallowed by this CSR bit,
which "solves" the problem of mixing and matching implementations that do it both ways.

On Thu, Oct 27, 2022 at 9:00 AM Ved Shanbhogue <ved@...> wrote:
On Thu, Oct 27, 2022 at 08:07:15AM +0200, Roger Espasa wrote:
>I would concur with Scott above. Clarifications to the spec belong in the
>spec itself, not inside an extension. If the Architecture Review Committee
>suggested otherwise, is it because the clarifications only pertain to the
>extension?
>

There were two motivations. One to name the specified behavior
and second to provide a control to select between the two
specified behaviors.

The specification for hardware updating of A/D bits existed
along with the specification for causing a (guest)page fault.
Whereas the behavior to cause a page-fault has an extension
name Ssptead, the behavior for hardware updating did not have
an extension name.

Hardware updating behavior is is now named Svadu and the
specification related to Svadu is now associated it. In the
provides the controls to select between the two specified
behaviors for A/D bits.

regards
ved

Re: Concern Raised in Tech Chair Meeting

Allen Baum

While, in general, CSR bits are either RW or RdOnly, there is one exception that I am aware of, and it is quite pertinent to your scenario
(as was intended to be from the beginning) and that is the lock bit in PMP entries, which is a W1S (write 1 to set) bit, so can only be cleared by a reset.
This has been extended in the Extended PMP spec that changes the behaviors of each entry
- but the bits that control these behaviors also have W1S behavior (though in a more complex way,
That may or may not be enough for security domains that you're concerned with.

On Thu, Oct 27, 2022 at 10:12 AM Guerney D H Hunt <gdhh@...> wrote:

The purpose of this e-mail is to start a discussion/debate around the issue that I raised in the tech-chairs meeting this week related the m-mode and the stability of the configuration.  It is important to state that there is nothing that I am discussing in the e-mail that would be considered confidential by my corporation.

As most of you will be realize I am relatively new to the RISC-V community since I started my participation earlier this year. I read the privilege specification and probably need to reread it. MY concern comes from my focus as a security researcher. Specifically, I am working on confidential computing.  My current focus included what I will call provable security. Some might call this “certifiable security”, referring to the various methods to certify the security strength of an apparatus. For the highest levels of certification, in general, a proof (mathematical) of the attributes of the system is required.  In this model, trust is not a replacement for proof. Just because something is trusted, does not mean that its attributes do not have to be verifiable (or proven). I apologize if I am expressing a concern that does not exist because I am still learning the architecture.

I did not do a good job of describing the concern in the tech chairs meeting.  I will try to be less expressive and clearer in this e-mail.  I have two areas of concern 1) attestation and 2) Proof.

Attestation is the notation that the configuration of a system can be confirmed by an external party (assuming the underlying system meets certain requirements). For confidential computing, the attestation must include information about the control status registers (CSRs) (hardware configuration).  Some, but not all, of the hardware configurations must be part of the attestation. It does not matter who owns the CSR if the attested value cannot change without a reset of the system. This requirement for confidential computing is reflected in TCG DICE in that notification is required if the configuration of a dedicated device is modified.  If this is not true, then the attestation is of little value because the remote party will not know whether the values represent the current configuration of the system.  If it existed,  “dynamic attestation” does not solve the problem because the remote party would not know for how long the values were accurate. Dynamic attestation can have value but not in this space.  The key phrase in my earlier statement is “but not all”. In my opinion this implies a requirement that those CSRs that affect the security of the system, or the security of confidential computing must be lockable. The lock must be verifiable and not changeable without rebooting the system. Simply put confidential computing requires that these registers can be locked, and their lock state is verifiable. Obviously if M-mode owns the CSR, then it would have to properly configure the CSR before locking (and measuring) it. This is not a requirement that it be locked in all versions of RISC-V, or M-mode firmware, etc. just those that support confidential computing.  This is work that AP-TEE group (and any other group implanting CC support for a variant of RISC-V) must do. In terms of implementation rather than the overkill of a global bit which freezes all CSRs, I prefer that those registers which are a concern should have a bit indicating that they have been locked or perhaps a locking register indicating that certain sets of registers have been locked.

Proof is a bit more complex. Addressing the issue at a high level, fundamentally hardware and software are both Touring complete.  This means that theoretically we can prove the attributes of the hardware (often called verification) and we can prove the attributes of software.  The more complex the hardware or software is, the more difficult a formal proof is. Obviously the more complex the hardware or software is, the more difficult is to prove its attributes. In general, for automated mathematical proofs of software one must also prove that the mathematical expression represents the actual coded unless there is an automated tool for deriving the expressions from the code. (a longer discussion). Some languages are easier to prove than others. However, for the work we are doing (bias warning) we need to establish invariants for our system and our mathematical proofs will verify or confirm that the invariants are not broken by the code. Since we are not yet focused on proving the hardware our invariants describe the environment provided by the hardware. The things that our proofs are based on should not (cannot) be mutable without hardware reset. Since we are focused on confidential computing, solving the issue for attestation should address our concerns.

I personally believe that attributes of the RISC-V architecture provide a better foundation for the types of work we are doing. If possible, it would be good to have proofs.

Guerney D. H. Hunt, Ph.D.

Senior Research Scientist

IBM T. J. Watson Research Center

--

Re: Fast-track extension proposal for H/W PTE A/D updating

Allen Baum

This is more than just clarifying and naming. It also defines a specfic WARL control bit. in an existing, defined CSR.
Individual WARL CSR bits can be RW, RdOnlyZero, or RdOnly1 (WARL *fields* can have infinitely more complex behaviors).
In the discussion, I believe it was also stated that RdOnly 1 was disallowed by this CSR bit,
which "solves" the problem of mixing and matching implementations that do it both ways.

On Thu, Oct 27, 2022 at 9:00 AM Ved Shanbhogue <ved@...> wrote:
On Thu, Oct 27, 2022 at 08:07:15AM +0200, Roger Espasa wrote:
>I would concur with Scott above. Clarifications to the spec belong in the
>spec itself, not inside an extension. If the Architecture Review Committee
>suggested otherwise, is it because the clarifications only pertain to the
>extension?
>

There were two motivations. One to name the specified behavior
and second to provide a control to select between the two
specified behaviors.

The specification for hardware updating of A/D bits existed
along with the specification for causing a (guest)page fault.
Whereas the behavior to cause a page-fault has an extension
name Ssptead, the behavior for hardware updating did not have
an extension name.

Hardware updating behavior is is now named Svadu and the
specification related to Svadu is now associated it. In the
provides the controls to select between the two specified
behaviors for A/D bits.

regards
ved

Concern Raised in Tech Chair Meeting

Guerney D H Hunt

The purpose of this e-mail is to start a discussion/debate around the issue that I raised in the tech-chairs meeting this week related the m-mode and the stability of the configuration.  It is important to state that there is nothing that I am discussing in the e-mail that would be considered confidential by my corporation.

As most of you will be realize I am relatively new to the RISC-V community since I started my participation earlier this year. I read the privilege specification and probably need to reread it. MY concern comes from my focus as a security researcher. Specifically, I am working on confidential computing.  My current focus included what I will call provable security. Some might call this “certifiable security”, referring to the various methods to certify the security strength of an apparatus. For the highest levels of certification, in general, a proof (mathematical) of the attributes of the system is required.  In this model, trust is not a replacement for proof. Just because something is trusted, does not mean that its attributes do not have to be verifiable (or proven). I apologize if I am expressing a concern that does not exist because I am still learning the architecture.

I did not do a good job of describing the concern in the tech chairs meeting.  I will try to be less expressive and clearer in this e-mail.  I have two areas of concern 1) attestation and 2) Proof.

Attestation is the notation that the configuration of a system can be confirmed by an external party (assuming the underlying system meets certain requirements). For confidential computing, the attestation must include information about the control status registers (CSRs) (hardware configuration).  Some, but not all, of the hardware configurations must be part of the attestation. It does not matter who owns the CSR if the attested value cannot change without a reset of the system. This requirement for confidential computing is reflected in TCG DICE in that notification is required if the configuration of a dedicated device is modified.  If this is not true, then the attestation is of little value because the remote party will not know whether the values represent the current configuration of the system.  If it existed,  “dynamic attestation” does not solve the problem because the remote party would not know for how long the values were accurate. Dynamic attestation can have value but not in this space.  The key phrase in my earlier statement is “but not all”. In my opinion this implies a requirement that those CSRs that affect the security of the system, or the security of confidential computing must be lockable. The lock must be verifiable and not changeable without rebooting the system. Simply put confidential computing requires that these registers can be locked, and their lock state is verifiable. Obviously if M-mode owns the CSR, then it would have to properly configure the CSR before locking (and measuring) it. This is not a requirement that it be locked in all versions of RISC-V, or M-mode firmware, etc. just those that support confidential computing.  This is work that AP-TEE group (and any other group implanting CC support for a variant of RISC-V) must do. In terms of implementation rather than the overkill of a global bit which freezes all CSRs, I prefer that those registers which are a concern should have a bit indicating that they have been locked or perhaps a locking register indicating that certain sets of registers have been locked.

Proof is a bit more complex. Addressing the issue at a high level, fundamentally hardware and software are both Touring complete.  This means that theoretically we can prove the attributes of the hardware (often called verification) and we can prove the attributes of software.  The more complex the hardware or software is, the more difficult a formal proof is. Obviously the more complex the hardware or software is, the more difficult is to prove its attributes. In general, for automated mathematical proofs of software one must also prove that the mathematical expression represents the actual coded unless there is an automated tool for deriving the expressions from the code. (a longer discussion). Some languages are easier to prove than others. However, for the work we are doing (bias warning) we need to establish invariants for our system and our mathematical proofs will verify or confirm that the invariants are not broken by the code. Since we are not yet focused on proving the hardware our invariants describe the environment provided by the hardware. The things that our proofs are based on should not (cannot) be mutable without hardware reset. Since we are focused on confidential computing, solving the issue for attestation should address our concerns.

I personally believe that attributes of the RISC-V architecture provide a better foundation for the types of work we are doing. If possible, it would be good to have proofs.

Guerney D. H. Hunt, Ph.D.

Senior Research Scientist

IBM T. J. Watson Research Center

gdhh@...

--

Re: Fast-track extension proposal for H/W PTE A/D updating

Ved Shanbhogue

On Thu, Oct 27, 2022 at 08:07:15AM +0200, Roger Espasa wrote:
I would concur with Scott above. Clarifications to the spec belong in the
spec itself, not inside an extension. If the Architecture Review Committee
suggested otherwise, is it because the clarifications only pertain to the
extension?
There were two motivations. One to name the specified behavior
and second to provide a control to select between the two
specified behaviors.

The specification for hardware updating of A/D bits existed
along with the specification for causing a (guest)page fault. Whereas the behavior to cause a page-fault has an extension
name Ssptead, the behavior for hardware updating did not have
an extension name.

Hardware updating behavior is is now named Svadu and the
specification related to Svadu is now associated it. In the
provides the controls to select between the two specified
behaviors for A/D bits.

regards
ved

Re: Fast-track extension proposal for H/W PTE A/D updating

Roger Espasa

I would concur with Scott above. Clarifications to the spec belong in the spec itself, not inside an extension. If the Architecture Review Committee suggested otherwise, is it because the clarifications only pertain to the extension?

On Thu, Oct 27, 2022 at 3:16 AM Aaron Durbin <adurbin@...> wrote:

On Wed, Oct 26, 2022 at 6:57 PM Scott Johnson <scott.johnson@...> wrote:

> On Oct 26, 2022, at 7:49 PM, Ved Shanbhogue <ved@...> wrote:
>
> I feel the following may be considered as significant:
>
> 1. Clarification that the rules outlined apply to PTE updates
>   caused by an explicit or an implicit memory access.
>
> 2. The text where the privileged spec stated "and the sequence is
>   interruptible." is updated to clarify that a trap may occur
>   between PTE update and the memory access that caused the PTE
>   update.
>

If these two are intended only as clarifications of what the privileged spec already says, then these clarifications should be made to the privileged spec, not here in this optional extension.

This path was suggested by the Architecture Review Committee. As noted up thread, hardware updateable PTE A/D bits were already in the spec. This extension is coining a name, and providing a bit more clarity to existing text.

Re: Fast-track extension proposal for H/W PTE A/D updating

Aaron Durbin

On Wed, Oct 26, 2022 at 6:57 PM Scott Johnson <scott.johnson@...> wrote:

> On Oct 26, 2022, at 7:49 PM, Ved Shanbhogue <ved@...> wrote:
>
> I feel the following may be considered as significant:
>
> 1. Clarification that the rules outlined apply to PTE updates
>   caused by an explicit or an implicit memory access.
>
> 2. The text where the privileged spec stated "and the sequence is
>   interruptible." is updated to clarify that a trap may occur
>   between PTE update and the memory access that caused the PTE
>   update.
>

If these two are intended only as clarifications of what the privileged spec already says, then these clarifications should be made to the privileged spec, not here in this optional extension.

This path was suggested by the Architecture Review Committee. As noted up thread, hardware updateable PTE A/D bits were already in the spec. This extension is coining a name, and providing a bit more clarity to existing text.

Re: Fast-track extension proposal for H/W PTE A/D updating

Scott Johnson

On Oct 26, 2022, at 7:49 PM, Ved Shanbhogue <ved@...> wrote:

I feel the following may be considered as significant:

1. Clarification that the rules outlined apply to PTE updates
caused by an explicit or an implicit memory access.

2. The text where the privileged spec stated "and the sequence is
interruptible." is updated to clarify that a trap may occur
between PTE update and the memory access that caused the PTE
update.
If these two are intended only as clarifications of what the privileged spec already says, then these clarifications should be made to the privileged spec, not here in this optional extension.

Re: Fast-track extension proposal for H/W PTE A/D updating

Earl Killian

My understanding of the situation (caveat: not my area of expertise) is that mixed software and hardware A/D updates is not likely to work in a system (perhaps because software is using locks and hardware using atomics?), and thus the existing priv spec, which could have led to such a mixture was considered problematic. It was therefore suggested that since: (1) almost all existing systems use software updates; and (2) in a system with mixed capabilities, it would be necessary to default to software updates; that: (a) it should be possible to turn off hardware updates on processors that support it; and (b) systems that support hardware A/D updates without an enable should be deprecated going forward. Someone not subject to the caveat above might want to correct the above, but I offering the above in the case it helps understand the purpose of Svadu.

On Oct 26, 2022, at 17:44, Scott Johnson <scott.johnson@...> wrote:

I concur; it is not apparent from this spec what is different vs. the long-existing implementation option to have hardware A/D updating. Is it only the new CSR bits?

This constraint appears new:

> Svadu extension requires the page tables to be located in cacheable main memory PMA regions.

What happens if they are not? Access fault? Unspecified?

On Oct 26, 2022, at 7:30 PM, John Ingalls <john.ingalls@...> wrote:

> "The A and D bits are managed by these extensions as follows: ..."

Does the scope of this extension include changing, constraining, or clarifying the behaviors already described in the Privileged ISA spec?  If yes, then I will follow up with more.  If not, then I suggest not opening that can of worms.  To limit this to just the CSR bits, can we say this instead for the content on page 3, and remove all the re-defining text?

"The A and D bits are managed by this extension as described in as specified in the Supervisor-Level ISA extension (section 4.3) and as modified by the hypervisor extension (section 8.5.1)."

On Wed, Oct 26, 2022 at 4:27 PM Ved Shanbhogue <ved@...> wrote:
Greetings !

We are submitting for your consideration an extension for HW PTE A/D updating (Svadu) controls.

As you might recall the privileged specification defines two HW behaviors for PTE A/D bits if they are 0 when required to be 1:
- to cause a (guest) page fault
- to update the A and/or D bits

This extension provides controls to select between the behaviors.

regards
ved

Re: Fast-track extension proposal for H/W PTE A/D updating

Ved Shanbhogue

On Wed, Oct 26, 2022 at 07:44:05PM -0500, Scott Johnson wrote:
This constraint appears new:

Svadu extension requires the page tables to be located in cacheable main memory PMA regions.
What happens if they are not? Access fault? Unspecified?
This is addressed by the step 2 and 7.a of the translation process:
2. If accessing pte violates a PMA or PMP check, raise
an access-fault exception corresponding to the
original access type.
7.a. If a store to pte would violate a PMA or PMP check,
raise an access-fault exception corresponding to the
original access type.

regards
ved

Re: Fast-track extension proposal for H/W PTE A/D updating

Ved Shanbhogue

John Ingalls wrote:

Does the scope of this extension include changing, constraining, or
clarifying the behaviors already described in the Privileged ISA spec? If
It is not a lot of text so request you to compare the two
to see if the edits may be considered significant.

I feel the following may be considered as significant:

1. Clarification that the rules outlined apply to PTE updates
caused by an explicit or an implicit memory access.

2. The text where the privileged spec stated "and the sequence is
interruptible." is updated to clarify that a trap may occur
between PTE update and the memory access that caused the PTE
update.

3. The extension requires page tables to be located in cacheable
main memory PMA regions.

regards
ved

Re: Fast-track extension proposal for H/W PTE A/D updating

Scott Johnson

I concur; it is not apparent from this spec what is different vs. the long-existing implementation option to have hardware A/D updating. Is it only the new CSR bits?

This constraint appears new:

> Svadu extension requires the page tables to be located in cacheable main memory PMA regions.

What happens if they are not? Access fault? Unspecified?

On Oct 26, 2022, at 7:30 PM, John Ingalls <john.ingalls@...> wrote:

> "The A and D bits are managed by these extensions as follows: ..."

Does the scope of this extension include changing, constraining, or clarifying the behaviors already described in the Privileged ISA spec?  If yes, then I will follow up with more.  If not, then I suggest not opening that can of worms.  To limit this to just the CSR bits, can we say this instead for the content on page 3, and remove all the re-defining text?

"The A and D bits are managed by this extension as described in as specified in the Supervisor-Level ISA extension (section 4.3) and as modified by the hypervisor extension (section 8.5.1)."

On Wed, Oct 26, 2022 at 4:27 PM Ved Shanbhogue <ved@...> wrote:
Greetings !

We are submitting for your consideration an extension for HW PTE A/D updating (Svadu) controls.

As you might recall the privileged specification defines two HW behaviors for PTE A/D bits if they are 0 when required to be 1:
- to cause a (guest) page fault
- to update the A and/or D bits

This extension provides controls to select between the behaviors.

regards
ved

Re: Fast-track extension proposal for H/W PTE A/D updating

John Ingalls

> "The A and D bits are managed by these extensions as follows: ..."

Does the scope of this extension include changing, constraining, or clarifying the behaviors already described in the Privileged ISA spec?  If yes, then I will follow up with more.  If not, then I suggest not opening that can of worms.  To limit this to just the CSR bits, can we say this instead for the content on page 3, and remove all the re-defining text?

"The A and D bits are managed by this extension as described in as specified in the Supervisor-Level ISA extension (section 4.3) and as modified by the hypervisor extension (section 8.5.1)."

On Wed, Oct 26, 2022 at 4:27 PM Ved Shanbhogue <ved@...> wrote:
Greetings !

We are submitting for your consideration an extension for HW PTE A/D updating (Svadu) controls.

As you might recall the privileged specification defines two HW behaviors for PTE A/D bits if they are 0 when required to be 1:
- to cause a (guest) page fault
- to update the A and/or D bits

This extension provides controls to select between the behaviors.

regards
ved

Fast-track extension proposal for H/W PTE A/D updating

Ved Shanbhogue

Greetings !

We are submitting for your consideration an extension for HW PTE A/D updating (Svadu) controls.

As you might recall the privileged specification defines two HW behaviors for PTE A/D bits if they are 0 when required to be 1:
- to cause a (guest) page fault
- to update the A and/or D bits

This extension provides controls to select between the behaviors.

regards
ved

Re: Is a Full VA or Block-Aligned VA Saved into *MTVAL on a page-fault?

David Kruckemyer

+tech-privileged@...

cc'ing mailing list, too....

On Fri, Oct 21, 2022 at 9:19 AM David Kruckemyer <dkruckemyer@...> wrote:
Hi Ricardo,

The original intent (which apparently was not captured in the spec) was that the effective address would be captured in *tval, just like a normal load or store.

I will add a clarification to the extension specification.

Cheers,
David

On Tue, Oct 18, 2022 at 3:48 PM Ricardo Ramirez <ricardo.ramirez@...> wrote:

When a breakpoint, access-fault, or page-fault exception occur on a CMO instruction (cbo.clean, cbo.flush, cbo.inval, cbo.zero), is the full virtual address provided in the register identified by rs1 saved into xtval or can a block-size aligned version of the VA be used?

Regards,
Ricardo

Is a Full VA or Block-Aligned VA Saved into *MTVAL on a page-fault?

Ricardo Ramirez

When a breakpoint, access-fault, or page-fault exception occur on a CMO instruction (cbo.clean, cbo.flush, cbo.inval, cbo.zero), is the full virtual address provided in the register identified by rs1 saved into xtval or can a block-size aligned version of the VA be used?

Regards,
Ricardo

Re: Fast-track extension proposal V3 for "Sv32 Svpbmt"

Guo Ren

On Thu, Aug 18, 2022 at 12:25 PM Greg Favor <gfavor@...> wrote:

On Wed, Aug 17, 2022 at 5:19 AM Guo Ren <guoren@...> wrote:

Here is the third version of the proposal.

It seems like you have dropped a bunch of text from the prior versions - which is probably part of what leads to some of my questions below.

\subsection{Svpbmt32'' Extension for Page-Based Memory Types}
\label{sec:translation}

Svpbmt32 support is being added to allow the two highest bits of a PTE
to be used as PBMT instead of PA[33:32] for Sv32.

Maybe better to say "The Svpbmt32 extension allows the two ..."
Okay

The S-mode and G-stage address translation under this extension are

"are" -> "is"
Okay

controlled by the
menvcfg.PBMTE. The VS-stage address translation under this extension
is controlled by henvcfg.PBMTE and indirectly by menvcfg.PBMTE.

This needs to specify what "controlled" means. There also is no explanation (here or below) of how menvcfg.PBMTE indirectly controls VS-stage address translation.

If this is all duplication of some of the currently defined *envcfg PBMTE functionality, then it is better to make clear that this is just reiterating a portion of the exact same functionality as currently exists for the *envcfg.PBMTE bits (and to refer to those current definitions for the details). Otherwise, by default, there is no clear understanding as to whether or not this extension specifies the exact same *envcfg.PBMTE behaviors as for the Svpbmt extension.
Okay, here is the rewritten sentence:

The Svpbmt32 extension allows the two highest bits of a PTE
(BIT[31:30]) to be used as PBMT (Page-Based Memory Type) instead of
PA[33:32] for Sv32. All modes and G-stage address translation under
this extension are controlled by the menvcfg.PBMTE. If menvcfg.PBMTE =
0, BIT[31:30] of PTE becomes PA[33:32]. If menvcfg.PBMTE = 1,
BIT[31:30] of PTE becomes PBMT for V=0. The henvcfg.PBMT is for V=1
and is controlled by menvcfg.PBMTE. If menvcfg.PBMTE = 0,
henvcfg.PBMTE couldn't be set to 1. If henvcfg.PBMTE = 1, BIT[31:30]
of PTE becomes PBMT for V=1 and G-stage address translation.

\begin{commentary}
For example, consider an RV32 system supporting Svpbmt32 and
Hypervisor Extension (Chapter~\ref{hypervisor}). When menvcfg.PBMTE=1,
Svpbmt32 is available for S-mode and G-stage address translation. When
henvcfg.PBMTE=1, Svpbmt32 is available for VS-mode address translation.

This is being presented as non-normative text, but this sounds like it is or needs to be normative text? Or is this "non-normatively" just repeating existing defined functionality - in which case what extra value is this text providing past repeating existing arch definitions?
Okay, I've moved the text into the above section. But I rewrote the
commentary with PBMT type mapping explanation. So I won't explain more
about PBMT usage for V=0/V=1 in the section.

\begin{commentary}
The mechanism of the PBMT of Sv32 is the same as Sv39, Sv48, and Sv57.
The only difference is the bits' location. Please see
(Chapter~\ref{Svpbmt}) for detail.
\end{commentary}

\end{commentary}

| 31 22 | 21 12 | 11 0 |
VPN[1] VPN[0] page offset
10 10 12

| 31 22 | 21 12 | 11 0 |
PPN[1] PPN[0] page offset
10 10 12

Sv32 page table entry with Svpbmt:

| 31 30 | 29 20 | 19 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
PBMT PPN[1] PPN[0] reserved for SW D A G U X W R V

========================================================================

There is no statement anywhere in this spec that says what exactly is the PBMT field. I know you intend for it to have the exact same definition as the currently defined PBMT field, but this should be stated explicitly (to remove any possible ambiguity around whether PBMT encodings and/or meanings may be a little different in RV32 versus RV64).
--
Best Regards
Guo Ren

Re: Fast-track extension proposal for Resumable Non-Maskable Interrupts (Smrnmi)

Andrew Waterman

If these registers are allowed to be reused for other purposes (e.g. another privilege mode), then those other purposes would either require masking NMIs or would make NMIs received in that mode non-resumable.  So it would seem to run counter to the purpose of this extension.

On Wed, Oct 5, 2022 at 2:13 AM Mark Hill <mark.hill@...> wrote:

Hi Andrew,

Just one thought, this change introduces a bank of context saving registers that could also be re-used/applied for additional purposes such as a lightweight TEE-OS (where we are looking at supporting primary and secondary m-mode contexts) and/or providing a separate attestable context for the m-mode TCB component in a confidential compute solution. I therefore wonder if a more generic naming scheme would be appropriate (e.g. mpepc for m-mode primary epc),  or perhaps we should “byte the bullet!” and address this requirement by adding a new privilege level (which this change adds most of the state needed to implement).

Mark

From: tech-privileged@... <tech-privileged@...> On Behalf Of Andrew Waterman
Sent: 04 October 2022 02:08
To: tech-privileged <tech-privileged@...>
Subject: [RISC-V] [tech-privileged] Fast-track extension proposal for Resumable Non-Maskable Interrupts (Smrnmi)

Hi,

We're submitting for your consideration an extension for resumable non-maskable interrupt (RNMI) support.

You might recall that the current non-maskable interrupt support defined in the M-mode chapter of the priv spec is unresumable (UNMI) when actioned from within M-mode.  While the optional UNMI facility continues to exist, we expect many NMI use cases will move to the RNMI scheme.

Re: Fast-track extension proposal for Resumable Non-Maskable Interrupts (Smrnmi)

Mark Hill

Hi Andrew,

Just one thought, this change introduces a bank of context saving registers that could also be re-used/applied for additional purposes such as a lightweight TEE-OS (where we are looking at supporting primary and secondary m-mode contexts) and/or providing a separate attestable context for the m-mode TCB component in a confidential compute solution. I therefore wonder if a more generic naming scheme would be appropriate (e.g. mpepc for m-mode primary epc),  or perhaps we should “byte the bullet!” and address this requirement by adding a new privilege level (which this change adds most of the state needed to implement).

Mark

From: tech-privileged@... <tech-privileged@...> On Behalf Of Andrew Waterman
Sent: 04 October 2022 02:08
To: tech-privileged <tech-privileged@...>
Subject: [RISC-V] [tech-privileged] Fast-track extension proposal for Resumable Non-Maskable Interrupts (Smrnmi)

Hi,

We're submitting for your consideration an extension for resumable non-maskable interrupt (RNMI) support.

You might recall that the current non-maskable interrupt support defined in the M-mode chapter of the priv spec is unresumable (UNMI) when actioned from within M-mode.  While the optional UNMI facility continues to exist, we expect many NMI use cases will move to the RNMI scheme.

Fast-track extension proposal for Resumable Non-Maskable Interrupts (Smrnmi)

Andrew Waterman

Hi,

We're submitting for your consideration an extension for resumable non-maskable interrupt (RNMI) support.

You might recall that the current non-maskable interrupt support defined in the M-mode chapter of the priv spec is unresumable (UNMI) when actioned from within M-mode.  While the optional UNMI facility continues to exist, we expect many NMI use cases will move to the RNMI scheme.

 61 - 80 of 1210