Question re sc and exception return

[Peter Ashenden]

Hi folks,

I'm a little unclear about the following in the RISC-V User-Level ISA V2.2 spec (p.41):

The SC must fail if ... in the meantime the hart executed a privileged exception-return instruction.

I presume "meantime" means since a lr instruction was last executed. Regarding "privileged exception-return instruction", does that just refer to an sret or mret instruction executed at any privilege level for which it's legal? Or does it also include a uret instruction? If it includes a uret, does it include execution at any privilege level (including U), or just at S or M level?

I know these include corner cases unlikely to be used in practice, but it would be good to have a clear and consistent specification. For cases that are unlikely to be used, specifying something simple to implement would be good (eg, any uret/sret/mret executed in any mode).

Thanks, and cheers,

PA

-- 
Peter Ashenden, CTO IC Design, ASTC

[Andrew Waterman]

Yes, we need to clean up the description here - "meantime" is indeed
unclear; privileged instructions shouldn't be mentioned in the user
spec if possible; and the matter of the N extension needs to be
addressed.

> --
> 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 post to this group, send email to isa...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/1da039a2-65d0-46cd-7f68-4e434e053024%40astc-design.com.

[Jacob Bachmeyer]

Andrew Waterman wrote:
> Yes, we need to clean up the description here - "meantime" is indeed
> unclear; privileged instructions shouldn't be mentioned in the user
> spec if possible; and the matter of the N extension needs to be
> addressed.
>

Since the eventual success guarantee is not valid if any SYSTEM
instruction is executed between LR and SC, and xRET are all SYSTEM
instructions, programs cannot depend on success of such a sequence.

Also, this interacts badly with systems that use trap-and-emulate, or
does the "A" extension require that all instructions permitted in a
"guaranteed eventual success" LR/SC sequence be actually implemented in
hardware? If so, this should be explicit.

Perhaps it could be better to specify "The SC must fail unless the
hardware can prove that there was no observable memory access from
another thread to the address since the LR that established the
reservation." ? (A context switch means that another U-mode thread was
running on "this" S-mode thread; the SC should be allowed to succeed if
the hardware can prove that the "other" U-mode thread did not touch the
reserved address. However, unless ASIDs are used, hardware is unlikely
to be able to ensure that, so the SC must also be allowed to fail.)
This avoids mentioning privileged operations in the user ISA manual.

On a related note, what is the (visible to user programs) difference, if
any, between a "hart" and a "thread"? Should the user ISA be revised to
mention only "threads" on the grounds that software-managed threads and
hardware-managed threads are indistinguishable?

-- Jacob

[kr...@berkeley.edu]

>>>>> On Thu, 05 Oct 2017 19:59:51 -0500, Jacob Bachmeyer <jcb6...@gmail.com> said:
| On a related note, what is the (visible to user programs) difference, if
| any, between a "hart" and a "thread"? Should the user ISA be revised to
| mention only "threads" on the grounds that software-managed threads and
| hardware-managed threads are indistinguishable?

User-level thread packages create a difference,

Krste

[Jacob Bachmeyer]

Good point. However, in the context of LR/SC, hardware does not know
when a user-level thread switch occurs, but a thread switch will almost
certainly run out the "16 integer instructions" clock, so success is not
guaranteed afterwards.

So we have user-level threads, supervisor-managed threads, and
hardware-managed threads. Should the user ISA distinguish between
supervisor-managed threads and hardware-managed threads? Are user-level
threads relevant to a user ISA spec at all or are they purely an
application-level detail? Could we simplify this and gain clarity for
atomic operations and the revised memory model?

I suggest defining some term for a thread that appears to be scheduled
by hardware, whether it is actually a hardware thread or an illusion
created by context-switching in a lower implementation level.


-- Jacob

[Andrew Waterman]

On Thu, Oct 5, 2017 at 5:59 PM, Jacob Bachmeyer <jcb6...@gmail.com> wrote:
> Andrew Waterman wrote:
>>
>> Yes, we need to clean up the description here - "meantime" is indeed
>> unclear; privileged instructions shouldn't be mentioned in the user
>> spec if possible; and the matter of the N extension needs to be
>> addressed.
>>
>
>
> Since the eventual success guarantee is not valid if any SYSTEM instruction
> is executed between LR and SC, and xRET are all SYSTEM instructions,
> programs cannot depend on success of such a sequence.

Indeed, I was getting at something stronger: LR/SC sequences with an
intervening user-level trap *must* fail, to prevent an atomicity
violation between two preemptive user-level threads.

Really, the only problem is that the current text only says that
*privileged* exception-returns must cause SC to fail. The text was
written before the N extension was proposed.

>
> Also, this interacts badly with systems that use trap-and-emulate, or does
> the "A" extension require that all instructions permitted in a "guaranteed
> eventual success" LR/SC sequence be actually implemented in hardware? If
> so, this should be explicit.

The commentary spells it out: "Floating-point operations and integer
multiply/divide were disallowed to simplify [...] emulation of these
instructions on implementations lacking appropriate hardware support."

>
> Perhaps it could be better to specify "The SC must fail unless the hardware
> can prove that there was no observable memory access from another thread to
> the address since the LR that established the reservation." ? (A context
> switch means that another U-mode thread was running on "this" S-mode thread;
> the SC should be allowed to succeed if the hardware can prove that the
> "other" U-mode thread did not touch the reserved address. However, unless
> ASIDs are used, hardware is unlikely to be able to ensure that, so the SC
> must also be allowed to fail.) This avoids mentioning privileged operations
> in the user ISA manual.
>
> On a related note, what is the (visible to user programs) difference, if
> any, between a "hart" and a "thread"? Should the user ISA be revised to
> mention only "threads" on the grounds that software-managed threads and
> hardware-managed threads are indistinguishable?
>
> -- Jacob
>

> --
> 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 post to this group, send email to isa...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
> To view this discussion on the web visit

> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/59D6D587.9050702%40gmail.com.