What, exactly, does the reservation set size (Za64rs/Za128rs) constrain?

[sorear]

A simple single-hart platform (among more exotic possibilities) would naturally provide atomicity across the entire address space for LR/SC pairs, regardless of addresses. In such a situation the natural size for the reservation set in the unprivileged ISA is the entire address space, but this is forbidden in RVA20 and RVA22. This is a strange requirement that software does not seem to be able to use beneficially in any reliable way.

What is such an implementation expected to do to be conformant with Za64rs? Force LR/SC instructions which are misaligned across a 64B boundary to trap and force SCs which do not reference the same 64B unit to fail?

What does software gain from a guarantee that LR will fail across 64B boundaries? There is no clear benefit to the memory model since a nonstandard extension accessing multiple 64B units is not forbidden.

What does software gain from a guarantee that SC will fail if it is not paired with a LR on the same 64B unit? Is it trying to prevent a storage channel (even though we require software to clear the reservation on context switches)? A property that constrained LR/SC loops operating on different 64B blocks will experience individual, rather than collective, eventual success (even though there is nothing to support this in the ISA manual's description of LR/SC eventuality)?

[aswaterman]

IIRC, the motivation was simply that, since the reservation set size is architecturally visible, it should be given a name, as we are trying to do for other architecturally visible properties.

Yes, the implication for implementations is that LR followed by SC to a different reservation set must fail. We aren't claiming that software can usefully take advantage of the guaranteed-failure property--but it is a visible property nonetheless.

There's also a performance justification to making the reservation set size known: on many implementations, LR/SC success probability will increase if contended synchronization variables are placed in different reservation sets. Even though this doesn't strengthen any architectural guarantees, it's still something that some software will want to be aware of in practice. And in some cases (e.g. https://github.com/torvalds/linux/blob/8395ae05cb5a2e31d36106e8c85efa11cda849be/arch/riscv/include/asm/cache.h#L12) the size can only be taken advantage of if it is statically known.

[kasanovic]

In the presence of virtual memory, it is already required than an SC fail if it is to a different page in memory (sec 5.3.1 in current priv arch document), so a simple implementation cannot reserve all of memory.

Given this requirement, there is little additional cost for single-hart RVA systems to fail SC outside of the 64-byte res. set, and this removes one small incompatibility. The advantage to software is the limit to the padding inserted between contended synchronization variables.