On Tue, Mar 30, 2021 at 7:56 AM Guo Ren <guoren@xxxxxxxxxx> wrote: > > On Mon, Mar 29, 2021 at 9:56 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > On Mon, Mar 29, 2021 at 2:52 PM Guo Ren <guoren@xxxxxxxxxx> wrote: > > > > > > On Mon, Mar 29, 2021 at 7:31 PM Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > > > > > > > > On Mon, Mar 29, 2021 at 01:16:53PM +0200, Peter Zijlstra wrote: > > > > > Anyway, an additional 'funny' is that I suspect you cannot prove fwd > > > > > progress of the entire primitive with any of this on. But who cares > > > > > about details anyway.. :/ > > > > > > > > What's the architectural guarantee on LL/SC progress for RISC-V ? > > > > > > funct5 | aq | rl | rs2 | rs1 | funct3 | rd | opcode > > > 5 1 1 5 5 3 5 7 > > > LR.W/D ordering 0 addr width dest AMO > > > SC.W/D ordering src addr width dest AMO > > > > > > LR.W loads a word from the address in rs1, places the sign-extended > > > value in rd, and registers a reservation set—a set of bytes that > > > subsumes the bytes in the addressed word. SC.W conditionally writes a > > > word in rs2 to the address in rs1: the SC.W succeeds only if the > > > reservation is still valid and the reservation set contains the bytes > > > being written. If the SC.W succeeds, the instruction writes the word > > > in rs2 to memory, and it writes zero to rd. If the SC.W fails, the > > > instruction does not write to memory, and it writes a nonzero value to > > > rd. Regardless of success or failure, executing an SC.W instruction > > > *invalidates any reservation held by this hart*. > > > > > > More details, ref: > > > https://github.com/riscv/riscv-isa-manual > > > > I think section "3.5.3.2 Reservability PMA" [1] would be a more relevant > > link, as this defines memory areas that either do or do not have > > forward progress guarantees, including this part: > > > > "When LR/SC is used for memory locations marked RsrvNonEventual, > > software should provide alternative fall-back mechanisms used when > > lack of progress is detected." > > > > My reading of this is that if the example you tried stalls, then either > > the PMA is not RsrvEventual, and it is wrong to rely on ll/sc on this, > > or that the PMA is marked RsrvEventual but the implementation is > > buggy. > Yes, PMA just defines physical memory region attributes, But in our > processor, when MMU is enabled (satp's value register > 2) in s-mode, > it will look at our custom PTE's attributes BIT(63) ref [1]: > > PTE format: > | 63 | 62 | 61 | 60 | 59 | 58-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > SO C B SH SE RSW D A G U X W R V > ^ ^ ^ ^ ^ > BIT(63): SO - Strong Order > BIT(62): C - Cacheable > BIT(61): B - Bufferable > BIT(60): SH - Shareable > BIT(59): SE - Security > > So the memory also could be RsrvNone/RsrvEventual. > > [1] https://github.com/c-sky/csky-linux/commit/e837aad23148542771794d8a2fcc52afd0fcbf88 Is this about your C-sky architecture or your RISC-V implementation. If these PTE bits are in your RISC-V implementation then clearly your RISC-V implementation is not compliant with the RISC-V privilege spec because these bits are not defined in RISC-V privilege spec. Regards, Anup > > > > > It also seems that the current "amoswap" based implementation > > would be reliable independent of RsrvEventual/RsrvNonEventual. > Yes, the hardware implementation of AMO could be different from LR/SC. > AMO could use ACE snoop holding to lock the bus in hw coherency > design, but LR/SC uses an exclusive monitor without locking the bus. > > > arm64 is already in the situation of having to choose between > > two cmpxchg() implementation at runtime to allow falling back to > > a slower but more general version, but it's best to avoid that if you > > can. > Current RISC-V needn't multiple versions to select, and all AMO & > LR/SC has been defined in the spec. > > RISC-V hasn't CAS instructions, and it uses LR/SC for cmpxchg. I don't > think LR/SC would be slower than CAS, and CAS is just good for code > size. > > > > > Arnd > > > > [1] http://www.five-embeddev.com/riscv-isa-manual/latest/machine.html#atomicity-pmas > > -- > Best Regards > Guo Ren > > ML: https://lore.kernel.org/linux-csky/
