Config option needed for PMP behavior on misaligned accesses that cross region boundaries

[UmerShahidengr]

While running the RISC-V architectural PMP tests, we observed a behavioral difference between Spike and the Sail reference model for misaligned memory accesses that cross PMP region boundaries (e.g., ld/sd straddling an NA4/TOR/NAPOT region).

This appears to be related to how misaligned accesses are handled internally by the implementation.

The RISC-V Privileged Specification (Section 3.7.1.3) states that on some implementations, misaligned loads, stores, and instruction fetches may also be decomposed into multiple accesses. Because of this allowance, there are two possible valid behaviors.

Spike

Spike treats the misaligned access as a single memory access.

Example:

sd 0(a5)

If the access width crosses a PMP region boundary (e.g., an NA4 region), Spike checks the entire access width against the matching PMP entry.
If the entry does not match all bytes of the access, Spike raises:

store_access_fault

---

Sail

Sail appears to decompose misaligned accesses into multiple aligned accesses.

For example, an ld or sd that straddles a PMP boundary is executed as two smaller accesses, each of which independently passes PMP checks.
As a result, no exception is raised.

---

Because the privileged spec explicitly allows implementations to either

1. Treat the misaligned access as a single access, or
2. Decompose it into multiple accesses

both Spike and Sail behaviors are architecturally allowed.

However, this difference causes problems when using Sail as a reference model for DUT comparison, because different implementations may follow either behavior. This difference currently causes mismatches in PMP architectural tests involving misaligned accesses that straddle PMP boundaries, including:

• misaligned_na4
• misaligned_tor
• misaligned_napot

The DUT may match either Spike-style behavior or Sail-style behavior depending on how misaligned accesses are implemented.

---

Introduce a configuration option in Sail controlling how misaligned accesses are handled during PMP checking.

Example:

pmp_misaligned_access_behavior = {single_access | decomposed_access}

Where:

single_access

• Treat the misaligned load/store as one access
• Check the entire access width against PMP
• If any byte falls outside the matching PMP entry → raise fault
• Matches Spike behavior

decomposed_access

• Decompose misaligned access into multiple aligned accesses
• Perform PMP checks per sub-access
• Matches current Sail behavior

[Timmmm]

We do have some options for this. Try setting memory.misaligned.allowed_within_exp to 11.

I think you should actually be able to set it to 12 - I don't know why the code limits it to 11. I'll make a PR for that.

Any misaligned access within a 2^allowed_within_exp NAPOT region will be done as one memory operation. It will only be split if it crosses one of those regions.

In general, this may not be sufficient, but modelling more complex options is going to be very difficult, especially while ensuring that page-crossing accesses work correctly.

[Timmmm]

#1615 will allow setting it to 12.

If that isn't sufficient there are some more options:

• Add a way to disable that check when virtual memory isn't enabled. That would be fairly easy.
• Add a way to disable that check when the access spans pages that are contiguously mapped. This would be quite complicated; I wouldn't hold your breath for this.
• Add support for discontiguous memory operations, so you always get one memory operation per memory access. I haven't thought this through but I suspect this would be complicated too. Especially if you want to do this for vector loads/stores.

[allenjbaum]

The ACTs had defined this as a boundary crossing bit position (where the value 0 meant naturally aligned, so 1 if byte, 2 if halfword, 3 if word, 4 if double, and no split if it is 64. So, that single parameter defines if it is split, and you either check once or twice, and if either access cross a PMA boundary, then you get an illegal access exception (I don't think you should get a misaligned exception in this kind of implementation)

…

On Fri, Mar 13, 2026 at 9:50 AM Tim Hutt ***@***.***> wrote: *Timmmm* left a comment (riscv/sail-riscv#1614) <#1614 (comment)> #1615 <#1615> will allow setting it to 12. If that isn't sufficient there are some more options: - Add a way to disable that check when virtual memory isn't enabled. That would be fairly easy. - Add a way to disable that check when the access spans pages that are contiguously mapped. This would be quite complicated; I wouldn't hold your breath for this. - Add support for discontiguous memory operations, so you always get one memory operation per memory access. I haven't thought this through but I suspect this would be complicated too. Especially if you want to do this for vector loads/stores. — Reply to this email directly, view it on GitHub <#1614 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJVX76L6OKRNPOE4TSL4QQ333AVCNFSM6AAAAACWRGSIROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANJWGUYTSNRYHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[anonymous-xtr]

I am facing a similar problem with instruction fetch.
dut: rv32ic with no misaligned memory access support.
case: misaligned pmp tests; fetch a 16bit aligned 32bit instruction matching two pmp regions.
Sail always does fetch in 16bit which passes pmp checks.
A legal implementation can fetch 32bits in this case, and pmp check would generate an exception.

I think an option is needed.

[pmundkur]

For instruction fetch, this could be handled with Ziccif (#1245): enabling it would give atomic fetches, disabling gives the current behavior.

[Timmmm]

I don't think Ziccif would cover @anonymous-xtr 's case because his instruction fetch isn't NAPOT and Ziccif only applies to NAPOT fetches as far as I can see?

This is a really to support it without potentially breaking page-crossing accesses we have to check if address translation is enabled before we actually do the access.

Definitely doable but it's not going to be easy.

[nadime15]

@Timmmm Unless I miss something but I think we have everything to handle a case like that we would only need to rewrite fetch():

private function fetch() -> FetchResult = {
  if get_config_rvfi() then return rvfi_fetch();

  if let Some(e) = ext_fetch_check_pc(PC, PC) then return F_Ext_Error(e);

  if PC[0] != 0b0 | (PC[1] != 0b0 & not(currentlyEnabled(Ext_Zca)))
  then return F_Error(E_Fetch_Addr_Align());

  let ppclo = match translateAddr(Virtaddr(PC), InstructionFetch()) {
    Err(e, _) => return F_Error(e),
    Ok(pa, _) => pa,
  };

  let ppchi = match translateAddr(Virtaddr(PC + 2), InstructionFetch()) {
    Err(e, _) => return F_Error(e),
    Ok(pa, _) => pa,
  };

  // Single 32-bit fetch: only valid if the two 16-bit granules are physically
  // contiguous (ppclo + 2 == ppchi). This naturally handles the page-crossing
  // case, if translation maps PC and PC+2 to different physical pages, the
  // addresses won't be contiguous and we skip the single fetch path.
  if config platform.is_single_fetch : bool & (ppclo + 2 == ppchi) then {
    match mem_read(InstructionFetch(), ppclo, 4, false, false, false) {
      Err(e)   => return F_Error(e),
      Ok(insn) => return if isRVC(insn[15..0]) then F_RVC(insn[15..0]) else F_Base(insn),
    }
  };

  // Decomposed: fetch low 16-bit granule first
  let ilo = match mem_read(InstructionFetch(), ppclo, 2, false, false, false) {
    Err(e)   => return F_Error(e),
    Ok(data) => data,
  };

  if isRVC(ilo) then return F_RVC(ilo);

  let PC_hi = PC + 2;
  if let Some(e) = ext_fetch_check_pc(PC, PC_hi) then return F_Ext_Error(e);

  match mem_read(InstructionFetch(), ppchi, 2, false, false, false) {
    Err(e)  => F_Error(e),
    Ok(ihi) => F_Base(append(ihi, ilo)),
  }
}

For the PMP case, mem_read with width=4 flows all the way down to pmpRangeMatch, which returns PMP_PartialMatch when the access straddles a region boundary, and pmpCheck unconditionally faults on PMP_PartialMatch. So @anonymous-xtr's case would correctly raise an access fault.

[pmundkur]

This would be easier with the fetch refactor I'm currently doing for Ziccif.

[Timmmm]

I don't think that code is quite correct @nadime15 - if you get an exception caused by the upper half of the access, but it's actually a 16-bit instruction then it should succeed anyway.

[pmundkur]

It looks like the Ziccif refactor doesn't help much. Could we just check translationMode(cur_privilege) == Bare, and then do an atomic fetch? The config parameter for this case should be explicit about applying to fetches without virtual memory.

[nadime15]

@Timmmm good point, what about the following?

private function fetch() -> FetchResult = {
  if get_config_rvfi() then return rvfi_fetch();

  if let Some(e) = ext_fetch_check_pc(PC, PC) then return F_Ext_Error(e);

  if PC[0] != 0b0 | (PC[1] != 0b0 & not(currentlyEnabled(Ext_Zca)))
  then return F_Error(exception_context(E_Fetch_Addr_Align(), PC));

  let ppclo = match translateAddr(Virtaddr(PC), InstructionFetch()) {
    Err(e, _) => return F_Error(e),
    Ok(pa, _) => pa,
  };

  // Fetch low 16-bit first to determine instruction size
  let ilo = match mem_read(InstructionFetch(), ppclo, 2, false, false, false) {
    Err(e)   => return F_Error(exception_context(e, PC)),
    Ok(data) => data,
  };

  if isRVC(ilo) then return F_RVC(ilo);

  // 32-bit instruction translate upper 16 bits
  let PC_hi = PC + 2;
  if let Some(e) = ext_fetch_check_pc(PC, PC_hi) then return F_Ext_Error(e);

  let ppchi = match translateAddr(Virtaddr(PC_hi), InstructionFetch()) {
    Err(e, _) => return F_Error(e),
    Ok(pa, _) => pa,
  };

  // Explicitly check PMP with full width=4 before doing the
  // two 16-bit reads. This way PMP sees the full access width without
  // double reading memory or triggering callbacks twice.
  if config platform.is_single_fetch : bool & (ppclo + 2 == ppchi) then {
    if let Some(e) = phys_access_check(InstructionFetch(), effectivePrivilege(InstructionFetch(), mstatus, cur_privilege), ppclo, 4, false) then
      return F_Error(e, PC);
  };

  match mem_read(InstructionFetch(), ppchi, 2, false, false, false) {
    Err(e)  => F_Error(e),
    Ok(ihi) => F_Base(append(ihi, ilo)),
  }
}

We would still split a 32-bit access into two 16-bit accesses, but we would only perform the appropriate checks when a single fetch access needs to be emulated.

[nadime15]

@pmundkur I dont think limiting this to Bare mode is the right approach. The issue is more general. A design could do a single 32bit fetch even with virtual memory enabled as long as the two halves of the instruction map to physically contiguous addresses. Restricting the config option to bare metal would make it less useful as a reference model.

[pmundkur]

We should add this to #1506 and work out a coherent strategy for all misaligned handling.

[Timmmm]

@nadime15 yeah I think that code works. It's a bit unfortunate that it does the access twice. I think real hardware would do a single access and just record which bytes caused an access fault (@anonymous-xtr can you confirm if your dut does that?) but our Sail code isn't really set up to do that.

It isn't entirely identical either because in the case where you have address translation enabled, if you do the full 4 byte access and throw away the upper access fault for 16-bit instructions you might set both PTE A(ccessed) bits, but if you first do a 2 byte access and then a 4 byte one you wouldn't. Unless the A bit doesn't get set on access faults? I'd have to double check that.

[anonymous-xtr]

@Timmmm yes. but I am lying (see below, it is not important imho).

disclaimer: the frontend is complex and I am still figuring out these finer details,

Here is my reasoning about this for rv32ic bare in a non trivial hardware design (if I remember correctly);

• pmp check can only happen after the earlier instruction commits (to guarentee pmp state is up to date).
• so, unlike in simulators, fetch pmp check is delayed in the pipeline.
• fetch always happens with pma checks only and it can be be any legal width/alignment.
• instruction realigner/decoder makes sure that the fetch information is recorded with each instruction.
• the instruction goes through the pipeline until it reaches the point where pmp check is done.
• there is enough information to know how the instruction was fetched and if there were errors (pma/bus/mem).
• pmp does its checks and records the results in the packet.
• the instruction goes through the pipeline and may generate the fault.

So depending on fetch width and alignment configuration in the design, a 16bit aligned 32bit instruction can be fetched in 1-mem-access or 2-mem-access or more, and that gives different results with pmp.
(to be honest, I don't understand/remember the rationale behind this in the spec).

The lie:

• My current instruction memory accesses are 32bit aligned 32bits wide. So 16bit aligned 32bit instruction requires 2-mem-accesse.
• I made a (discussable) simplification that makes 2-mem-accesse fetch look like a 1-mem-access fetch for pmp.
• If I widen the memory subsystem to 64bits (or maybe relax its alignment), the case will happen without my discussable simplifacation.
• this is why I am saying I am lying and it does not matter really, as the case can happen per spec.