On Tue, Mar 30, 2021 at 1:51 PM Anup Patel <anup@xxxxxxxxxxxxxx> wrote: > > 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. It's in 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. We could disable it if the vendor's SOC has a coherency interconnect bus, so C910 is compliant with standard privilege spec. ps: I remember someone has mentioned a similar design in 1.12-draft-VM-TASKGROUP: "Bit 63 indicates that the PTE uses a custom implementation-specific encoding. If bit 63 is set, the algorithm for virtual-to-physical address translation is implementation-defined. If bit 63 is not set, the algorithm for virtual-to-physical address translation is described in Section 4.4.2. Bit 62 indicates the use of naturally aligned power-of-two (NAPOT) address translation contiguity, as described in Section 4.4.2. Bits 61–xx indicate cacheability attributes associated with the virtual address in question, as de-scribed in Section 4.4.3. Bits xx–54 are reserved for future use." > > 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/ -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
