Public review for standard extension Svinval

396 views
Skip to first unread message

Stephano Cetola

unread,
Sep 16, 2021, 8:07:58 PM9/16/21
to isa...@groups.riscv.org, Dan Lustig, Andrea Mondelli
We are delighted to announce the start of the public review period for
the following proposed standard extension to the RISC-V ISA:
Svinval - Fast TLB Invalidation

The review period begins today, Thursday Sept 16, and ends on Sunday
Oct 31 (inclusive).

This extension is part of the Privileged Specification.

This extension is described in the PDF spec available at:
https://github.com/riscv/virtual-memory/blob/main/specs/668-Svinval.pdf

To respond to the public review, please either email comments to the
public isa-dev mailing list or add issues to the Virtual Memory GitHub
repo: https://github.com/riscv/virtual-memory.

We welcome all input and appreciate your time and effort in helping us
by reviewing the specification.

During the public review period, corrections, comments, and
suggestions, will be gathered for review by the Virtual Memory Task
Group. Any minor corrections and/or uncontroversial changes will be
incorporated into the specification. Any remaining issues or proposed
changes will be addressed in the public review summary report. If
there are no issues that require incompatible changes to the public
review specification, the Privileged ISA Committee will recommend the
updated specifications be approved and ratified by the RISC-V
Technical Steering Committee and the RISC-V Board of Directors.

Thanks to all the contributors for all their hard work.

Kind Regards,
Stephano
--
Stephano Cetola
Director of Technical Programs
RISC-V International

Paul Donahue

unread,
Sep 27, 2021, 6:25:30 PM9/27/21
to RISC-V ISA Dev, step...@riscv.org, Daniel Lustig, Andrea Mondelli
The SFENCE.W.INVAL instruction guarantees that any previous stores already visible to the current RISC-V hart are ordered before subsequent SINVAL.VMA instructions issued by the same hart.  The SFENCE.INVAL.IR instruction guarantees that any previous SINVAL.VMA instructions issued by the current hart are ordered before subsequent implicit references by that hart to the memory-management data structures. 
When issued in order (but not necessarily consecutively) by a single hart, the sequence SFENCE.W.INVAL, SINVAL.VMA, and SFENCE.INVAL.IR has the same effect as a hypothetical SFENCE.VMA instruction

Is there a definition for "issued"?  Is this about architectural program order or do microarchitectural concepts of issuing and speculative execution come into play?  This definition uses different terminology than SFENCE.VMA so I'm wondering if there is some subtlety about that.


Thanks,

-Paul

Andrew Waterman

unread,
Sep 27, 2021, 6:30:36 PM9/27/21
to Paul Donahue, RISC-V ISA Dev, step...@riscv.org, Daniel Lustig, Andrea Mondelli
On Mon, Sep 27, 2021 at 3:25 PM Paul Donahue <pdon...@ventanamicro.com> wrote:
The SFENCE.W.INVAL instruction guarantees that any previous stores already visible to the current RISC-V hart are ordered before subsequent SINVAL.VMA instructions issued by the same hart.  The SFENCE.INVAL.IR instruction guarantees that any previous SINVAL.VMA instructions issued by the current hart are ordered before subsequent implicit references by that hart to the memory-management data structures. 
When issued in order (but not necessarily consecutively) by a single hart, the sequence SFENCE.W.INVAL, SINVAL.VMA, and SFENCE.INVAL.IR has the same effect as a hypothetical SFENCE.VMA instruction

Is there a definition for "issued"?  Is this about architectural program order or do microarchitectural concepts of issuing and speculative execution come into play?  This definition uses different terminology than SFENCE.VMA so I'm wondering if there is some subtlety about that.

I don't think the definition was actually intended to draw this distinction.  It should probably say "executed" in both places.
 
--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/a898314a-bc9a-43cb-8a94-98642c185067n%40groups.riscv.org.

Dan Lustig

unread,
Sep 28, 2021, 9:12:41 AM9/28/21
to Andrew Waterman, Paul Donahue, RISC-V ISA Dev, step...@riscv.org, Andrea Mondelli
On 9/27/2021 6:30 PM, Andrew Waterman wrote:
> On Mon, Sep 27, 2021 at 3:25 PM Paul Donahue <pdon...@ventanamicro.com>
> wrote:
>
>> The SFENCE.W.INVAL instruction guarantees that any previous stores already
>> visible to the current RISC-V hart are ordered before subsequent SINVAL.VMA
>> instructions *issued *by the same hart. The SFENCE.INVAL.IR instruction
>> guarantees that any previous SINVAL.VMA instructions *issued *by the
>> current hart are ordered before subsequent implicit references by that hart
>> to the memory-management data structures.
>> When *issued *in order (but not necessarily consecutively) by a single
>> hart, the sequence SFENCE.W.INVAL, SINVAL.VMA, and SFENCE.INVAL.IR has
>> the same effect as a hypothetical SFENCE.VMA instruction
>>
>> Is there a definition for "issued"? Is this about architectural program
>> order or do microarchitectural concepts of issuing and speculative
>> execution come into play? This definition uses different terminology than
>> SFENCE.VMA so I'm wondering if there is some subtlety about that.
>>
>
> I don't think the definition was actually intended to draw this
> distinction. It should probably say "executed" in both places.

Indeed. No such subtlety was intended; this is just about architectural
program order.

Thanks,
Dan
>> <https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/a898314a-bc9a-43cb-8a94-98642c185067n%40groups.riscv.org?utm_medium=email&utm_source=footer>
>> .
>>
>

Allen Baum

unread,
Sep 30, 2021, 8:50:07 PM9/30/21
to Dan Lustig, Andrew Waterman, Paul Donahue, RISC-V ISA Dev, step...@riscv.org, Andrea Mondelli
The perhaps just replace "issued" with "in program order"

Reply all
Reply to author
Forward
0 new messages