Skip to content
This repository has been archived by the owner on Nov 1, 2023. It is now read-only.

Describe misaligned data access scenarios #2

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
58 changes: 58 additions & 0 deletions riscv-unix.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,9 @@ previous value stored to that location. (That is, the fetched instruction is
not an unpredictable value, nor is it a hybrid of the bytes of the old and new
values.)

LR/SC forward progress is guaranteed on main-memory regions that are cacheable
and coherent.

Unless otherwise specified by a given I/O device,
I/O regions are at least point-to-point strongly ordered.
All devices attached to a given PCIe root complex are on the same ordered
Expand All @@ -43,3 +46,58 @@ be on the same ordering channel.

On RV64I-based Unix-class systems the negative virtual addresses are
reserved for the kernel.

## Misaligned Physical-Memory Access Atomicity

Consider a data memory access of size *w* to physical address *p<sub>0</sub>*,
where *w* does not evenly divide *p<sub>0</sub>*. Let *p<sub>1</sub>* denote
the physical address of the last byte of the access, and let *P* denote the
address pair *(p<sub>0</sub>, p<sub>1</sub>)*. There are two cases:

1. *P* lies within a single physical-memory region. One of the following
holds:

1. Loads and stores to *P* execute atomically with respect to other
accesses to *P*. AMOs to *P* either execute atomically
with respect to other accesses to *P* or raise access
exceptions. LRs and SCs to *P* either execute atomically
with respect to other accesses to *P* or raise access exceptions.

2. Loads and stores to *P* execute without guarantee of atomicity. AMOs,
LRs, and SCs to *P* raise access exceptions.

2. *P* spans two physical-memory regions. AMOs, LRs, and SCs all raise access
exceptions. Additionally, one of the following holds:

1. Loads and stores to *P* raise access exceptions.

2. Loads and stores to *P* succeed without guarantee of atomicity.

3. Loads and stores to *P* proceed partially, then raise access exceptions.
No register writebacks occur.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is awkward. What's the reason for it?

Copy link
Contributor Author

@aswaterman aswaterman Jan 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This happens when emulating misaligned loads & stores in M-mode software, when the access spans two pages. The load or store proceeds bytewise but encounters a page fault or access exception once it hits the second page.

This means that a store can complete partially then trap. For loads, it only matters for memory regions that have side effects. Usually, the load case will never happen, since such regions should forbid misaligned accesses altogether.


## Misaligned Virtual-Memory Access Atomicity

Consider a data memory access of size *w* to virtual address *v<sub>0</sub>*,
where *w* does not evenly divide *v<sub>0</sub>*. Let *v<sub>1</sub>* denote
the virtual address of the last byte of the access. Let *p<sub>0</sub>* and
*p<sub>1</sub>* be the physical addresses corresponding to *v<sub>0</sub>* and
*v<sub>1</sub>*, if translations exist. One of the following must hold:

1. *v<sub>0</sub>* is an impermissible virtual address; the access raises
a page-fault exception with trap value *v<sub>0</sub>*.

3. *v<sub>0</sub>* is a permissible virtual address; *v<sub>1</sub>* lies
in a different, impermissible page.
The access raises a page-fault exception with a trap value equal
to the base virtual address of the page containing *v<sub>1</sub>*.
Alternatively, if the same access to physical-address pair
*(p<sub>0</sub>, p<sub>0</sub>+w-1)* would have caused an access exception,
the implementation may raise that exception instead. (This design
simplifies the emulation of misaligned accesses in more-privileged software.)

3. *v<sub>0</sub>* and *v<sub>1</sub>* are both permissible virtual
addresses.
The access proceeds according to the misaligned physical-memory access
rules above, noting that *v<sub>0</sub>* and *v<sub>1</sub>* may lie
in different physical-memory regions, despite their virtual contiguity.