1. Topics
  2. Fast-track extension proposal for H/W PTE A/D updating

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.

Please find the PDF and source here: https://github.com/riscv/riscv-svadu

Please add comments/issues in github or to this thread.

regards
ved
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.

Please find the PDF and source here: https://github.com/riscv/riscv-svadu

Please add comments/issues in github or to this thread.

regards
ved
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.

Please find the PDF and source here: https://github.com/riscv/riscv-svadu

Please add comments/issues in github or to this thread.

regards
ved
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
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
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.

Please find the PDF and source here: https://github.com/riscv/riscv-svadu

Please add comments/issues in github or to this thread.

regards
ved
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.
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.
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.
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
process a few clarifications were added as noted and Svadu
provides the controls to select between the two specified
behaviors for A/D bits.

regards
ved
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
process a few clarifications were added as noted and Svadu
provides the controls to select between the two specified
behaviors for A/D bits.

regards
ved
John Ingalls
 


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
process a few clarifications were added as noted and Svadu
provides the controls to select between the two specified
behaviors for A/D bits.

regards
ved
1 - 12 of 12