crc: Add vector-accelerated assembly code for RISC-V 64-bit architecture with Zvbc instruction set by yinlenree · Pull Request #350 · intel/isa-l

yinlenree · 2025-07-23T12:23:19Z

I have implemented vector-accelerated CRC modules (including CRC16, CRC32, and CRC64) using the RISC-V V, Zbc and Zvbc instruction sets, with full functional verification and performance testing completed.

The implementation primarily leverages the vclmul.v and vclmulh.v (carry-less multiply) instructions for data folding. For big-endian processing, it additionally utilizes vrgather.vv instructions for byte-order reversal. The final checksum is computed via Barrett reduction.

pablodelara · 2025-07-25T09:06:54Z

Hi @yinlenree. I suggest you include commit title like
"crc: add RISC-V implementation" and then you can include your current commit message as the body.
@sunyuechi, can you review this PR? Thanks!

sunyuechi · 2025-07-25T09:20:20Z

I'll review it carefully next week. For now, I’ve noticed two issues:

If the compiler doesn't support those -march options, the newly added CRC files will still be compiled, leading to build failures.

Some files have trailing blank lines at the end，please remove all of them.

Some files have mixed indentation using both spaces and tabs. Please make them consistent. (You can see the differences using git diff.)

yinlenree · 2025-07-25T10:52:57Z

Understood, thank you both for the suggestions. I'll first address the compilation-related issues. This might take some time since I haven't worked on this aspect before.

sunyuechi · 2025-08-01T09:09:25Z

configure.ac

+				__asm__ volatile(
+					".option arch, +zbc\n"
+					"clmul zero, zero, zero\n"
+          "clmulh zero, zero, zero\n"


Please use either tabs or spaces consistently for indentation, and check other files as well.

sunyuechi · 2025-08-01T09:09:58Z

include/riscv64_multibinary.h

 #include <sys/auxv.h>
+#include <asm/hwprobe.h>  // 包含 RISC-V 硬件探测相关的宏定义（如 RISCV_HWPROBE_EXT_ZBB）
+#include <unistd.h>       // 提供系统调用相关声明
+#include <sys/syscall.h>  // 定义 __NR_riscv_hwprobe 系统调用号


Please use English comments, and check other files as well.

pablodelara · 2025-08-01T09:35:34Z

crc/riscv64/crc_riscv64_dispatcher.c

+DEFINE_INTERFACE_DISPATCHER(crc32_gzip_refl)
+{
+#if HAVE_RVV && HAVE_ZBC && HAVE_ZVBC && HAVE_ZVBB
+        struct riscv_hwprobe _probe = INIT_PROBE_STRUCT();


All these lines (from 131 to 135) are always the same throughout this file. Would be better to move it to a separate function.

I wrote a function to determine experimental extensions, while the logic for standard extensions remains unchanged. Do you think this is acceptable?
DEFINE_INTERFACE_DISPATCHER(crc16_t10dif)
{
#if HAVE_RVV && HAVE_ZBC && HAVE_ZVBC && HAVE_ZVBB
unsigned long auxval = getauxval(AT_HWCAP);
if (auxval & HWCAP_RV('V') && CHECK_RISCV_EXTENSIONS("ZVBC", "ZVBB", "ZBC")) {
return crc16_t10dif_vclmul;
}
#endif
return crc16_t10dif_base;
}

Looks tidier, yes

yinlenree · 2025-08-04T01:48:19Z

Understood. I will revise my code and comments according to the requirements. Thank you both for the review.

sunyuechi · 2025-08-06T11:50:27Z

include/riscv64_multibinary.h

+#define EXT_CODE(ext) ( \
+	strcmp(ext, "ZBC") == 0 ? 7 : \
+	strcmp(ext, "ZVBB") == 0 ? 17 : \
+	strcmp(ext, "ZVBC") == 0 ? 18 : -1)


Please use macros instead of these numbers, for example: RISCV_HWPROBE_EXT_ZBC, RISCV_HWPROBE_EXT_ZVBB, ...

sunyuechi · 2025-08-06T11:50:40Z

include/riscv64_multibinary.h

+static inline int check_riscv_extensions(const char **extensions, size_t count)
+{
+	struct riscv_hwprobe _probe = INIT_PROBE_STRUCT();
+	syscall(__NR_riscv_hwprobe, &_probe, 1, 0, NULL, 0);


It seems that using hwprobe requires checking the kernel version?

Okay, I will replace the numbers with macros. Additionally, regarding the extension check, I plan to use version 6.8 as the cutoff—versions below this will not utilize the ZVBC vector acceleration.

Considering that the linux/version.h file may change after a kernel upgrade, making it impossible to determine whether the current kernel supports RISC-V extension macros using the LINUX_VERSION_CODE macro, I plan to directly check whether these extension macros are defined to decide the code distribution. The code is as follows.

#if defined(RISCV_HWPROBE_EXT_ZBC) && defined(RISCV_HWPROBE_EXT_ZVBB) && defined(RISCV_HWPROBE_EXT_ZVBC) #define EXT_CODE(ext) ( \ strcmp(ext, "ZBC") == 0 ? RISCV_HWPROBE_EXT_ZBC : \ strcmp(ext, "ZVBB") == 0 ? RISCV_HWPROBE_EXT_ZVBB : \ strcmp(ext, "ZVBC") == 0 ? RISCV_HWPROBE_EXT_ZVBC : \ -1) #endif ... static inline int check_riscv_extensions(const char **extensions, size_t count) { #ifdef EXT_CODE struct riscv_hwprobe _probe = INIT_PROBE_STRUCT(); syscall(__NR_riscv_hwprobe, &_probe, 1, 0, NULL, 0); for (size_t i = 0; i < count; i++) { if (!(_probe.value & EXT_CODE(extensions[i]))) { return 0; } } return 1; #else return 0; #endif }

Do you think this is okay?

My understanding is that the detection works by checking whether asm/hwprobe.h exists in the kernel, since these files didn’t exist before.

I found that in the kernel code from versions 6.4 to 6.7, although there is an hwprobe.h file in the include/asm directory, it lacks macros for offsets of extensions like ZVBC, ZBC, etc. These macros were only defined after version 6.8.
Additionally, I noticed that the offset for the V standard extension was defined in version 6.5. Does this mean I also need to check the definition of the V extension offset?
I'm unsure whether there was an interface for detecting extensions like ZVBC in kernels from versions 6.4 to 6.7. I have little experience in this area. Do you have any suggestions?
Here's the URL for the hwprobe.h file in Linux kernel 6.7 from the official repository:
https://github.com/torvalds/linux/blob/v6.7/arch/riscv/include/asm/hwprobe.h
The macro definitions are located here.
https://github.com/torvalds/linux/blob/v6.7/arch/riscv/include/uapi/asm/hwprobe.h

Maybe we can directly detect this macro, similar to how DPDK introduced hwprobe, with a minimum requirement of kernel 6.8?
https://inbox.dpdk.org/dev/20240827153230.52880-2-daniel.gregory@bytedance.com/

Yes, the bitmasks for ZVBC and ZBC were defined starting from version 6.8. I plan to add detection macros for the hwprobe.h file during the compilation phase, as well as detection macros for the bitmasks of these three extensions: ZVBC, ZVBB, and ZBC.

sunyuechi · 2025-08-24T11:30:49Z

Please test what happens if the kernel does not have hwprobe support, for example, by changing asm/hwprobe.h to a non-existent file. Currently, this causes a build error.

yinlenree · 2025-08-28T02:12:37Z

@sunyuechi I forgot to add the conditional check before including the asm/hwprobe.h header file. I've now fixed it and optimized the code, replacing time-consuming instructions and removing the Zvbb extension.

pablodelara · 2025-09-10T09:26:52Z

Could you review this PR again, @sunyuechi? I am thinking of first merging the "prefetch" PR and then this PR (after they are reviewed, of course).

sunyuechi · 2025-09-10T15:34:01Z

@pablodelara Okay, I'll check it tomorrow.

sunyuechi · 2025-09-10T15:57:53Z

crc/riscv64/crc_common_vclmul.h

+#define vec_15        v15
+#define vec_16        v16
+#define vec_17        v17
+#define vec_18        v18


#define tmp_0 t0 #define tmp_1 t1 #define tmp_2 t2 #define tmp_3 t3 #define tmp_4 t4 #define tmp_5 t5 #define vec_0 v0 #define vec_1 v1 ... #define vec_10 v10 #define vec_11 v11 #define vec_12 v12

Please remove these #define statements that do not improve readability, these t and v registers are already sufficiently clear on their own.

sunyuechi · 2025-09-10T16:16:17Z

crc/riscv64/crc_common_vclmul.h

+#define len           a2
+
+// return
+#define crc_ret       a0


Okay, understood. I will remove these redundant and unused #define statements.

sunyuechi · 2025-09-11T08:04:30Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+    vxor.vv v0, v8, v3
+
+    addi sp, sp, -16
+    vse64.v v0, (sp)


t5 and t6 are unused and can be utilized to eliminate stack operations.

sunyuechi · 2025-09-11T08:04:57Z

crc/riscv64/crc16_t10dif_vclmul.S

+    vslideup.vi v8, v9, 1
+    vxor.vv v0, v8, v3
+
+    addi sp, sp, -16


t5 and t6 are unused and can be utilized to eliminate stack operations.

sunyuechi · 2025-09-11T08:05:24Z

crc/riscv64/crc32_refl_common_vclmul.h

+    addi t4, t4, 16
+    crc_fold_512b_to_128b
+
+    addi sp, sp, -16


Please use t6 to reduce stack operations (and also check other files as well).

sunyuechi · 2025-09-11T08:08:41Z

crc/riscv64/crc16_t10dif_vclmul.S

+    ret
+
+.crc_fold:
+    # Initialize vector registers


This comment seems to be describing the purpose of vset, but it feels a bit unclear. Could we adjust it slightly?

sunyuechi · 2025-09-11T08:10:27Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+    ret
+
+.crc_fold:
+    # Initialize vector registers


This comment seems to be describing the purpose of vset, but it feels a bit unclear. Could we adjust it slightly?

Okay, I will replace stack pointer (sp) operations with idle registers in all files and improve the readability of comments in the code.

sunyuechi · 2025-09-11T12:59:45Z

crc/riscv64/crc_riscv64_dispatcher.c

+{
+#if HAVE_RVV && HAVE_ZBC && HAVE_ZVBC
+        unsigned long auxval = getauxval(AT_HWCAP);
+        if (auxval & HWCAP_RV('V') && CHECK_RISCV_EXTENSIONS("ZVBC", "ZBC")) {


According to the RISC-V manual,

The Zvknhb and Zvbc Vector Crypto Extensions — and accordingly the composite extensions Zvkn and Zvks — require a Zve64x base, or application ("V") base Vector Extension.

Since the vector instructions you are using exist in both Zve64x and V, it seems that if Zvbc is detected, there’s no need to additionally check for the V extension. Please also review whether any changes are needed in the compilation part regarding this.

Got it. I will try to place the detection of Zvbc before that of the V extension, so as to omit the check for the V extension. Thank you.

yinlenree · 2025-09-12T08:58:00Z

I have retained the stack pointer operations when calling crc32_iscsi_refl_vclmul, which are used to save the call information.

sunyuechi · 2025-09-12T09:03:48Z

It seems that the check in the file crc_riscv64_dispatcher.c has not been updated.

yinlenree · 2025-09-12T09:42:00Z

It seems that the check in the file crc_riscv64_dispatcher.c has not been updated.

Sorry, I forgot about this. Now I have removed the HAVE_RVV macro from both the dispatcher and the assembly file.

sunyuechi · 2025-09-12T10:42:10Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+    .word 0x4ba80000, 0xc01f0000, 0xd7710000, 0x5cc60000, 0xf9ad0000, 0x721a0000, 0x65740000, 0xeec30000
+    .word 0xa4150000, 0x2fa20000, 0x38cc0000, 0xb37b0000, 0x16100000, 0x9da70000, 0x8ac90000, 0x017e0000
+    .word 0x1f650000, 0x94d20000, 0x83bc0000, 0x080b0000, 0xad600000, 0x26d70000, 0x31b90000, 0xba0e0000
+    .word 0xf0d80000, 0x7b6f0000, 0x6c010000, 0xe7b60000, 0x42dd0000, 0xc96a0000, 0xde040000, 0x55b30000


Can you extract a .h file like crc32/64?
(crc/riscv64/crc16_t10dif_vclmul.S and crc/riscv64/crc16_t10dif_copy_vclmul.S)
Since the data is completely identical, many parts of the crc_fold_loop calculation .. are also the same.

I did not create a .h header file for crc16_t10dif_copy because its procedural code involves memory copying compared to other algorithm implementations. I only extracted the data for the calculation. Do you think this is acceptable?

sunyuechi · 2025-09-12T10:44:41Z

crc/riscv64/crc_riscv64_dispatcher.c

+{
+#if HAVE_ZBC && HAVE_ZVBC
+        unsigned long auxval = getauxval(AT_HWCAP);
+        if (auxval & HWCAP_RV('V') && CHECK_RISCV_EXTENSIONS("ZVBC", "ZBC")) {


The runtime v check can also be removed.

sunyuechi · 2025-09-12T10:45:32Z

crc/riscv64/crc16_t10dif_vclmul.S

+
+.crc_table_loop:
+    lbu a4, 0(a1)
+    add a1, a1, 1


This may cause errors in certain environments. For immediates, please use the standard addi whenever possible (and please check other files as well).

Okay, I will check my code.

sunyuechi · 2025-09-24T03:15:08Z

crc/riscv64/crc64_rocksoft_refl_vclmul.h

+    .set    .lanchor_crc_tab,. + 0
+    .type   crc64_table_rocksoft_refl, %object
+    .size   crc64_table_rocksoft_refl, 2048
+crc64_table_rocksoft_refl:


It looks like there is no naming conflict with C here. How about changing it to use the same name?
crc64_table_rocksoft_refl -> crc64_rocksoft_refl_table (including other files).

sunyuechi · 2025-09-24T03:15:38Z

crc/riscv64/Makefile.am

+	crc/riscv64/crc64_jones_refl_vclmul.S \
+	crc/riscv64/crc64_jones_norm_vclmul.S \
+	crc/riscv64/crc64_rocksoft_refl_vclmul.S \
+	crc/riscv64/crc64_rocksoft_norm_vclmul.S


All files end with the warning "No newline at end of file", please add it.

Understood, it has been modified.

sunyuechi · 2025-09-30T03:47:27Z

I have implemented vector-accelerated CRC modules (including CRC16, CRC32, and CRC64) using the RISC-V V, Zbc, Zvbc, and Zvbb instruction sets, with full functional verification and performance testing completed.

The implementation primarily leverages the vclmul.v and vclmulh.v (carry-less multiply) instructions for data folding. For big-endian processing, it additionally utilizes vrev8.v, vslideup.vi, and vslidedown.vi instructions for byte-order reversal. The final checksum is computed via Barrett reduction.

Maybe you could remove the description about Zvbb here. Also, what hardware did you use for testing, and how was the performance?

In addition, has the performance gap between using only Zbc and using Zbc+Zvbc been tested? (Since it’s unclear whether Zvbc might cause a performance regression.)

It would be helpful if you could provide some performance analysis or other perspectives comparing this PR’s implementation: #299

yinlenree · 2025-09-30T08:13:32Z

I'm testing on a QEMU virtual machine, and since the execution bandwidth of vector and scalar instructions is uncertain, I haven't compared the performance of Zvbc + Zbc versus Zbc alone on QEMU.

pablodelara · 2025-10-15T13:05:48Z

After the latest updates on main, this needs rebase.

pablodelara · 2025-11-05T14:35:09Z

@sunyuechi could you review the PR again?

sunyuechi · 2025-11-07T12:40:57Z

As discussed earlier, I hope to provide clearer performance test results or performance-related explanations, similar to https://github.com/intel/isa-l/pull/299 or other performance optimization PRs. @pablodelara

pablodelara · 2025-11-24T15:23:11Z

@sunyuechi are those perf test results expected from @yinlenree?

sunyuechi · 2026-01-16T15:38:10Z

Hi, could you summarize what the major recent changes did?
Also, please refer to #381 and stop passing different -march values by default; otherwise, compiling C code may generate illegal instructions, which cannot be resolved at runtime.

pablodelara · 2026-01-19T12:38:47Z

I also recommend rebasing the PR against latest master.

yinlenree · 2026-01-20T01:23:51Z

OK, during this period, I optimized the single-vector folding approach in the main loop to a method using vector-plus-scalar folding, maximizing utilization of the execution units within the core. The performance test of "make perf" shows this method outperforms all previous implementations, and the performance data has already been sent to you via email. @sunyuechi
Subsequently, as mentioned in this issue, I removed the modifications related to -march in the configure.ac file and added .option directives to the assembly files in the crc/riscv64 and erasure_code/riscv64 directories.
And I am now rebasing the PR.

sunyuechi · 2026-01-25T10:57:19Z

configure.ac

+			AC_MSG_CHECKING([whether compiler supports RISC-V Extension (ZBB)])
+			AC_COMPILE_IFELSE(
+				[AC_LANG_PROGRAM([#include <asm/hwprobe.h>], [
+					int a = RISCV_HWPROBE_EXT_ZBC;


sunyuechi · 2026-01-25T10:59:04Z

configure.ac

+						".option arch, +v, +zvbc\n"
+						"vsetivli zero, 2, e64, m1, ta, ma\n"
+						"vclmul.vv v0, v0, v0\n"
+						"vclmulh.vv v0, v0, v0\n"


It’s sufficient to check either cmul or cmulh

sunyuechi · 2026-01-25T10:59:29Z

configure.ac

+						".option arch, +v, +zvbc\n"
+						"vsetivli zero, 2, e64, m1, ta, ma\n"
+						"vclmul.vv v0, v0, v0\n"
+						"vclmulh.vv v0, v0, v0\n"


It’s sufficient to check either vcmul or vcmulh

sunyuechi · 2026-01-25T11:02:31Z

include/riscv64_multibinary.h

 #else /* __ASSEMBLY__ */
 #include <sys/auxv.h>
+#if HAVE_HWPROBE_H
+#include <asm/hwprobe.h>


Newer versions of glibc use sys/hwprobe.h, so a similar approach should be used in the relevant places.

#if HAVE_SYS_HWPROBE_H #include <sys/hwprobe.h> #elif HAVE_ASM_HWPROBE_H #include <asm/hwprobe.h>

sunyuechi · 2026-01-25T11:04:16Z

include/riscv64_multibinary.h

+	check_riscv_extensions((const char*[]){ __VA_ARGS__ }, \
+							sizeof((const char*[]){ __VA_ARGS__ })/sizeof(const char*))
+#endif
+


The compile-time logic around hwprobe here is a bit odd. It might be better to wrap all hwprobe-related code together, with an outer check for hwprobe itself and inner checks for hwprobe macros such as ZBC, ZBB, and ZVBC, for example:

#if HAVE_SYS_HWPROBE_H || HAVE_ASM_HWPROBE_H #if zbc zbb ...

sunyuechi · 2026-01-25T11:14:21Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+
+    slli a0, a0, 32
+    la t4, .shuffle_data_mask
+    addi sp, sp, -120


According to the calling convention, it should be 16-byte aligned.

In the standard RISC-V calling convention, the stack grows downward and the stack pointer is always kept 16-byte aligned.

sunyuechi · 2026-01-25T11:26:01Z

crc/riscv64/crc16_t10dif_copy_vclmul.S

+    clmulh a5, a4, s1
+    clmulh ra, a4, s3
+    clmulh gp, a4, s5
+    clmulh tp, a4, s7


Using ra, gp, tp as temporary registers violates ABI conventions. Is this necessary? If so, comments should be added to explain this.

Got it. I've applied the changes as requested above.

pablodelara · 2026-01-29T16:15:00Z

configure.ac

+		fi
+		if test "x$sys_hwprobe_h" = "xyes"; then
+			AC_DEFINE([HAVE_SYS_HWPROBE_H], [1], [Define if sys/hwprobe.h exists])
+			AM_CONDITIONAL([HAVE_SYS_HWPROBE_H], [true])


CI is reporting an issue on x86: configure: error: conditional "HAVE_SYS_HWPROBE_H" was never defined.

Got it. I forgot the definition in configure.ac. I have updated the file accordingly.

The CRC module of ISA-L has been accelerated using RISC-V's V, Zbc, Zbb and Zvbc, instruction sets, implementing data folding and Barrett reduction optimizations. Signed-off-by: Ji Dong <dong.ji1@zte.com.cn>

pablodelara · 2026-02-02T14:16:45Z

@sunyuechi could you review this last revision? Thanks!

pablodelara · 2026-02-09T11:31:19Z

@sunyuechi sorry for pinging you again, but would be good to have this reviewed ASAP. Release date is end of this month and I would like new optimizations to be merged by the end of this week.

pablodelara · 2026-02-16T17:57:01Z

Last call for this PR to be integrated in v2.32, thanks. @sunyuechi can you review it please? Thanks!

yinlenree force-pushed the add-crc-riscv-vector-support branch from cd1a52d to 3259ef2 Compare July 24, 2025 03:36

yinlenree force-pushed the add-crc-riscv-vector-support branch 3 times, most recently from adef254 to 2379b73 Compare August 1, 2025 02:31

sunyuechi reviewed Aug 1, 2025

View reviewed changes

pablodelara reviewed Aug 1, 2025

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from 2379b73 to 740d8a4 Compare August 6, 2025 07:18

sunyuechi reviewed Aug 6, 2025

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from fe7ba9c to 0d79c34 Compare August 22, 2025 02:44

yinlenree force-pushed the add-crc-riscv-vector-support branch from 0d79c34 to ddd6706 Compare August 28, 2025 02:02

sunyuechi reviewed Sep 10, 2025

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from ddd6706 to a2ee08c Compare September 11, 2025 06:59

sunyuechi reviewed Sep 11, 2025

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from a2ee08c to ade80d5 Compare September 12, 2025 08:42

yinlenree force-pushed the add-crc-riscv-vector-support branch from ade80d5 to 56e655a Compare September 12, 2025 09:42

sunyuechi reviewed Sep 12, 2025

View reviewed changes

sunyuechi mentioned this pull request Sep 15, 2025

erasure_code: add prefetch and vsetvli optimization #351

Closed

yinlenree force-pushed the add-crc-riscv-vector-support branch from 56e655a to cf87b79 Compare September 17, 2025 14:08

sunyuechi reviewed Sep 24, 2025

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from cf87b79 to 67f153b Compare September 25, 2025 11:57

yinlenree force-pushed the add-crc-riscv-vector-support branch from 67f153b to d42e43b Compare November 3, 2025 01:49

yinlenree force-pushed the add-crc-riscv-vector-support branch from d42e43b to 5313ac9 Compare December 29, 2025 09:48

yinlenree force-pushed the add-crc-riscv-vector-support branch 2 times, most recently from d75406a to e674fbb Compare January 21, 2026 01:33

sunyuechi reviewed Jan 25, 2026

View reviewed changes

yinlenree force-pushed the add-crc-riscv-vector-support branch from e674fbb to 81dcddc Compare January 28, 2026 06:48

pablodelara reviewed Jan 29, 2026

View reviewed changes

crc: add RISC-V implementation

aed015e

The CRC module of ISA-L has been accelerated using RISC-V's V, Zbc, Zbb and Zvbc, instruction sets, implementing data folding and Barrett reduction optimizations. Signed-off-by: Ji Dong <dong.ji1@zte.com.cn>

yinlenree force-pushed the add-crc-riscv-vector-support branch from 81dcddc to aed015e Compare January 30, 2026 02:12

Conversation

yinlenree commented Jul 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pablodelara commented Jul 25, 2025

Uh oh!

sunyuechi commented Jul 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yinlenree commented Jul 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yinlenree commented Aug 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sunyuechi commented Aug 24, 2025

Uh oh!

yinlenree commented Aug 28, 2025

Uh oh!

pablodelara commented Sep 10, 2025

Uh oh!

sunyuechi commented Sep 10, 2025

Uh oh!

sunyuechi Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yinlenree commented Sep 12, 2025

Uh oh!

sunyuechi commented Sep 12, 2025

Uh oh!

yinlenree commented Sep 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

yinlenree commented Jul 23, 2025 •

edited

Loading

sunyuechi commented Jul 25, 2025 •

edited

Loading

sunyuechi Sep 10, 2025 •

edited

Loading

sunyuechi commented Sep 30, 2025 •

edited

Loading