How does MMIO memory fit into the memory model, and can reference point to it?

[chorman0773]

This question is intended to replace #33 and #265, and ask the general question of whether or not we can have a type, either user-defined or language-provided, that, when wrapped in a shared reference, guarantees that no accesses are introduced at the operational semantics level that are not part of the original program (and thus, if volatile accesses only are used, an implementation won't introduce any speculative reads).
If such a type can exist, the second question is what is the operational semantics of retagging as a shared reference to such a type.

[RalfJung]

I think the question whether we "can" have is fairly straight-forward -- yes, we can totally do that. I think it wouldn't be too hard either, operationally speaking. For instance we could say that &T where T contains a VolatileCell is exempt from all forms of dereferencability requirements. Most likely those requirements will stem from the aliasing model, not any kind of validity of value representations, but at least in Tree Borrows it would be trivial to skip any kind of "fake read" that might otherwise check a reference for being dereferenceable. (In fact right now Tree Borrows already skips the fake read for &!Frozen, and relies on other parts of Miri checking dereferenceability, but in MiniRust that would not work.)

For UnsafeCell there is a lot of demand for more precise tracking, reflexing in the opsem that only parts of memory allow shared mutation. Does that even make sense for VolatileCell? When doing MMIO, I assume it's always the entire memory block that needs to be treated volatile, and there's no other non-volatile memory behind the same reference?

[Dirbaio]

Is this something that is actually needed?

The main use case is making "register layout structs" in Peripheral Access Crates (PACs):

struct MyRegisterBlock {
   foo: VolatileCell<u32>,
   bar: VolatileCell<u32>,
   baz: VolatileCell<u32>,
}
struct VolatileCell<T: Copy>(UnsafeCell<T>);
impl<T> VolatileCell<T> {
   fn read(&self) -> T { self.0.get().read_volatile() }
   fn write(&self, val: T) { self.0.get().write_volatile(val) }
}

let regs: &MyRegisterBlock = &*(0x4000_0000 as *const MyRegisterBlock);
regs.foo.write(0x42);

However, you can accomplish the same thing by staying entirely within raw pointers:

struct MyRegisterBlock(*mut u32);
impl MyRegisterBlock {
   fn foo(&self) -> Reg<u32> { Reg(self.0.add(0)) }
   fn bar(&self) -> Reg<u32> { Reg(self.0.add(1)) }
   fn baz(&self) -> Reg<u32> { Reg(self.0.add(2)) }
}
struct Reg<T: Copy>(*mut T);
impl<T> Reg<T> {
   fn read(&self) -> T { self.0.read_volatile() }
   fn write(&self, val: T) { self.0.write_volatile(val) }
}

let regs: MyRegisterBlock = MyRegisterBlock(0x4000_0000 as _);
regs.foo().write(0x42);

Pros and cons:

• The latter clearly avoids all issues with speculative reads, since it never creates references.
• They're both equally ergonomic to use. The only change is .foo vs .foo().
• The former is shorter to write: you get rustc to lay out the struct for you, instead of having to do pointer maths. However, I don't think this is an advantage, because PACs are usually autogenerated with tools like svd2rust or chiptool, rarely written by hand.
• The struct approach breaks down anyway if registers overlap (can happen if same address has different meaning based on some mode, or if the same reg can be accessed as e.g. u16 and u32). svd2rust has code to detect that, and fall back to generating code similar to the raw pointer approach.

So overall, I don't think there's any reason to prefer the struct approach.

in Embassy we've been using PACs generated by chiptool, which generates code using raw pointers, out of concerns for the dereferenceable / speculative reads issue. It's been working well so far, we haven't found anything that it can't do that the struct approach could.

So IMO it's not worth it to add exceptions to the memory model to support usages like VolatileCell. It's not needed, you can do everything fine without.

[RalfJung]

I'm an outsider here and totally happy with not having VolatileCell, if the domain experts say that the status quo is totally sufficient.

@Lokathor has opinions on this topic, IIRC.

[chorman0773]

I specifically would like VolatileCell as it does make exposing MMIO via magic symbols (rather than magic addresses) a bit more ergonomic IMO.

[Lokathor]

My opinions are:

• The voladdress crate has types that store usize+PhantomData<T> because that makes it easy to work with in const contexts. It turns the usize into an actual pointer at the last possible moment, allowing almost everything except the read and write ops themselves to be const fn.
• My crate works extremely well for me personally. I'm entirely satisfied with it. If you want to find someone who needs more from the language than what is currently possible you'll have to look around. Perhaps @phil-opp has a strong opinion? They're in charge of the volatile crate and have been tinkering with the design of a next version for a while now I think.

---

@Dirbaio I think what people "really want" is something that also has magical field projection so that you can do code like this:

#[repr(C)]
pub struct Controls {
  display_control: u16,
  display_status: u16,
  vcount: u16,
}

pub const MMIO: &VolatileCell<Controls> = whatever_expression_here!(0x0400_0000);

fn main() {
  // magical field projection from `&VolatileCell<Controls>` into `&VolatileCell<u16>`
  let display: &VolatileCell<u16> = &MMIO.display_control;

  // call some method to assign some value
  display.write(1);

  // or we can chain the expression
  let y: u16 = MMIO.vcount.read();
}

I think without some sort of field projection thing added to the language it's less compelling, though possibly still useful even then. Also note that the above example doesn't bother with when things are unsafe or not, which things are readable or writable, etc. There's a lot of design that can go into an mmio abstraction type.

@chorman0773 can you say more about that linker stuff? I think you told me once but I've forgotten if you did, and more details about that might make a more compelling case for needing VolatileCell or might explain what constraints might apply.

[chorman0773]

can you say more about that linker stuff

Yes. In SNES-Dev, I use linker scripts to define access to the MMIO registers. For stuff that is specific to SNES-Dev, the address is even actualy known at compile time, as it is generally assigned by the linker itself, and given a special type in the mapping table.

[Lokathor]

That part sounds similar to GBA dev, but with GBA it's generally done with just const values, no linker involved. I'm unclear on why you'd want to have the linker involved at all.

[thejpster]

@Dirbaio in your example, MyRegisterBlock is no longer a ZST. Can that approach work without holding on to the pointer?

[phil-opp]

Thanks for the mention!

As far as I know, volatile cells are still commonly used in the Rust embedded an OS ecosystems. For example:

• Many popular projects still depend on the volatile_register crate, even though it is not suitable for MMIO.
  • The cortex-m uses volatile_register in it's public API, e.g. for accessing SysTick.
  • Also used in riscv crate, but I think only internally.
• The Tock project defines its own VolatileCell type.
• The Theseus project also defines a custom cell-like type based on an older version of the volatile crate.

Most of these projects are aware that this approach is not sound, but still haven't changed their code. I assume that it's a mix of personal preference (structs are much easier to write than doing manual pointer arithmetic) and migration cost (requires breaking changes across the entire ecosystem). So I think that there is definitely demand for a sound VolatileCell type.

[phil-opp]

@Dirbaio

• The former is shorter to write: you get rustc to lay out the struct for you, instead of having to do pointer maths. However, I don't think this is an advantage, because PACs are usually autogenerated with tools like svd2rust or chiptool, rarely written by hand.

I agree that it's less of an issue when the pointer arithmetic is generated by tools. However, I think most people write things by hand first and then create tools to autogenerate the boilerplate code later using the same design. So the design that is easier to write by hand is often used for code generation too. For example, I think svd2rust generates code that is based on the volatile_register crate, at least for Cortex M.

[bjorn3]

• The voladdress crate has types that store usize+PhantomData<T> because that makes it easy to work with in const contexts. It turns the usize into an actual pointer at the last possible moment, allowing almost everything except the read and write ops themselves to be const fn.

That is not compatible with CHERI, right? For CHERI you did at least have to store a raw pointer to preserve the full capability.