Opsem extension proposal: atomic volatile accesses

[RalfJung]

Our current volatile APIs do not let people write semantically correct MMIO with a DMA device. The interaction with such a device typically looks as follows:

• set up some data somewhere in regular memory using regular stores
• emit a kind of release fence
• write a single value to an MMIO register to tell the device that the data is ready

If the final write is just volatile but not atomic, then the data writes and the MMIO write are not guaranteed to happen in any particular order in the real (concrete) execution. A volatile write is observably-ordered wrt all other observable events (volatile accesses and I/O), but not observably-ordered wrt non-volatile memory accesses. A release fence only does something when there's a data write before the fence and an atomic write after the fence. So to get the desired semantics,
we need to make that write atomic.

Note that here I am using "atomic" in the sense of the C++ memory model. This is separate from the question of whether the write can tear or not. An atomic operation must be compiled in a way that avoids tearing, but the converse does not hold -- an operation can be non-torn while still also being non-atomic.

Another way to view this: a volatile store is basically a syscall, so the compiler treats it kind of like an opaque function call -- except that the compiler makes a lot of assumptions about the possible side-effects of that call: it cannot read or write any Rust-accessible memory except for the locations that the store overwrites. It also cannot read or write the "synchronization state" of the current thread, i.e. the set of memory events that that thread has observed or that can participate in fence-based synchronization. (In LLVM terms, volatile accesses are nosync.) However, to explain what happens in the DMA setting, we want the volatile MMIO write to interact with the synchronization state (specifically, the set of memory events in the "release fence" state of the current thread is made available to anyone reading from this volatile write). We need to tell the compiler that this operation may synchronize (i.e., we need to get rid of the nosync). The way we typically do this is by making an operation atomic, so we should have atomic volatile accesses.

So, I propose that t-opsem should decide that Rust shall have atomic volatile accesses: operations that are both observable (i.e., like I/O) and participate in the concurrency memory model. The exact API is left to t-libs-api; there is an ACP for it at rust-lang/libs-team#801.

[RalfJung]

@rfcbot fcp merge opsem

[rust-rfcbot]

@RalfJung has proposed to merge this. The next step is review by the rest of the tagged team members:

• @CAD97
• @RalfJung
• @digama0
• @joshlf
• @saethlin

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Lokathor]

I do want to point out that you can get correct semantics for your DMA under current Rust as long as you use volatile writes to fill your source buffer before you use the volatile write that activates the DMA.

This is not ideal in probably the majority of cases, and so we should do this opsem extension, but I thought it's worth noting down.

[CAD97]

This is an operation serving a need and doesn't impose any significant burden on the opsem to support. I concur; the Rust AM should provide this operation.

@rustbot reviewed

As an aside, I want to note that describing typical volatile writes as not being (implicit: strongly) ordered w.r.t. other writes was a confusing point to me a few times; operations in a single thread are always sequenced-before later operations in the same thread. The actual break in ordering is the (in)ability of the nonatomic volatile write to happens-before a "later" observing read.

This may just be a difference in the shape of how the relations are established. My mental model doesn't actually have a name for the effectively stronger sequenced-before relation between two writes if the latter write is release-ordered, since it's largely equivalent to the C++ description of the memory ordering model.

Rather than say "there's not really any ordering," I think I would have phrased it "can't establish any ordering [to a reading thread]."

you can get correct semantics [if] you use volatile writes to fill your source buffer @Lokathor

This is the case if the reading side records the externally observable events and never reads Rust memory, as no ordering with the memory (even the addresses previously volatile written to) has been established. I think that caveat cannot break your as-if story¹, but the logic could be somewhat tenuous. A release-ordered trigger is clearly the correct model, anyway.

Footnotes

1. The entire story of volatile writes to standard Rust memory is weird. The write is considered externally observable, but the only effect of the write is to change the value in Rust memory, and the only way to observe what the value changed to is to perform a Rust read, which is required to fit in the standard ordering that ignores volatile entirely. So I guess the external observer knows that a write happened, but to know what value got written requires additional synchronization?

   That is why I worded that caveat the way I did. You'd need observable writes to write an observable value, to record them, and then read from your side table, to avoid reading from Rust memory. Then you would show that reading from the physical memory cannot possibly produce a different result and use that proof to remove the side table.

   Or just use atomic aquire-release synchronization directly. ↩

[Diggsey]

I think you clearly justified the need for an atomic volatile access, but haven't explained why non-atomic volatiles are useful. I'm sure they are, but it might be worth mentioning a typical use-case where a non-atomic volatile is both correct and necessary performance-wise?

[bjorn3]

At least one example for where non-atomic volatiles are valid is devices that don't do DMA. For example a UART where you read or write a byte at a time from a device register rather than pointing the UART to a memory location. As for performance, I have no clue if it matters.

[RalfJung]

As an aside, I want to note that describing typical volatile writes as not being (implicit: strongly) ordered w.r.t. other writes was a confusing point to me a few times; operations in a single thread are always sequenced-before later operations in the same thread.

I was talking about the order in which the operations actually happen on the hardware level. That order does not have to respect happens-before. For example, it is legal for the compiler to reorder two non-atomic writes to different locations despite the fact that there is a happens-before relationship between them.

This order is only really meaningful between two observable events (volatile access or I/O), so maybe a more correct version of what I said would be that non-volatile accesses do not participate in this order and it is hence meaningless to ask whether, in the concrete execution, a non-volatile store occurs before or after a volatile store.

I think you clearly justified the need for an atomic volatile access, but haven't explained why non-atomic volatiles are useful. I'm sure they are, but it might be worth mentioning a typical use-case where a non-atomic volatile is both correct and necessary performance-wise?

Indeed I have not. Those accesses already exist and we cannot remove them due to backwards compatibility, so discussing their motivation here seems off-topic to me.

[RalfJung]

The entire story of volatile writes to standard Rust memory is weird.

Yes indeed. There is a world in which volatile writes are only permitted to non-Rust memory. But at this point I think that would be too much of a breaking change.

[Diggsey]

Those accesses already exist and we cannot remove them due to backwards compatibility, so discussing their motivation here seems off-topic to me.

Removing them would be, but making the existing volatile accesses atomic would not be a backwards incompatible change.

[RalfJung]

Yes it would be... or you'll have to clarify what you mean.
Adding the atomic bit to these operations in the LLVM IR we generate would break all volatile loads and stores that don't have the right size or alignment to be made into atomic operation.

[Diggsey]

Adding the atomic bit to these operations in the LLVM IR we generate would break all volatile loads and stores that don't have the right size or alignment to be made into atomic operation.

Well that answers the question I had: both operations are needed because regular volatile operations have weaker size and alignment requirements, so both variants are required.