Hi Oliver On Fri, Apr 4, 2025 at 4:01 PM Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > On Fri, Apr 04, 2025 at 10:06:59PM +0000, Raghavendra Rao Ananta wrote: > > Atomic instructions such as 'ldset' over (global) variables in the guest > > is observed to cause an EL1 data abort with FSC 0x35 (IMPLEMENTATION > > DEFINED fault (Unsupported Exclusive or Atomic access)). The observation > > was particularly apparent on Neoverse-N3. > > > > According to DDI0487L.a C3.2.6 (Single-copy atomic 64-byte load/store), > > it is implementation defined that a data abort with the mentioned FSC > > is reported for the first stage of translation that provides an > > inappropriate memory type. It's likely that the same rule also applies > > to memory attribute mismatch. When the guest loads the memory location of > > the variable that was already cached during the host userspace's copying > > of the ELF into the memory, the core is likely running into a mismatch > > of memory attrs that's checked in stage-1 itself, and thus causing the > > abort in EL1. > > Sorry, my index of the ARM ARM was trashed when we were discussing this > before. > > DDI0487L.a B2.2.6 describes the exact situation you encountered, where > atomics are only guaranteed to work on Inner/Outer Shareable MT_NORMAL > memory. > > What's a bit more explicit for other memory attribute aborts (like the > one you've cited) is whether or not the implementation can generate the > abort solely on the stage-1 attributes vs. the combined stage-1/stage-2 > attributes at the end of translation. > > Either way, let's correct the citation to point at the right section. > Ah yes, DDI0487L.a B2.2.6 seems to be very close. OTOH DDI0487L.a C3.2.6 explains why we see an abort in EL1. I can cite both to get a full picture. Thank you. Raghavendra > Thanks, > Oliver
