On 5/19/26 09:22, James Hilliard wrote:
+typedef struct MIPSOcteonCryptoState {
+ uint64_t des3_key[3];
+ uint64_t des3_iv;
+ uint64_t des3_result;
+ uint64_t hsh_iv[4];
+ uint64_t hsh_dat[8];
+ uint64_t hsh_ivw[8];
+ uint64_t hsh_datw[16];
+ uint64_t aes_iv[2];
+ uint64_t aes_key[4];
+ uint64_t aes_result[2];
+ uint64_t aes_input[2];
+ uint64_t gfm_mul[2];
+ uint64_t gfm_resinp[2];
+ uint64_t gfm_xor0;
+ uint64_t gfm_reflect_mul[2];
+ uint64_t gfm_reflect_resinp[2];
+ uint64_t gfm_reflect_xor0;
+ uint16_t gfm_poly;
+ uint8_t aes_keylen;
+ uint32_t shared_mode;
+ uint32_t crc_poly;
+ uint32_t crc_iv;
+ uint32_t crc_len;
+ uint32_t snow3g_fsm[3];
+ uint32_t snow3g_lfsr[16];
+ uint64_t snow3g_result;
+} MIPSOcteonCryptoState;
It might be easier if these were sorted to match Table 2-2.
Why do you use uint32_t crc_len for CRCLEN<3:0>?
There is no gfm_xor0 or gfm_reflect_xor0 in table 2-2.
I suspect your implementations of CVM_MT_GFM_XOR0 and CVM_MT_GFM_XOR0_REFLECT
are wrong.
hsh_dat[8] is mis-sized? Compared to HASHDAT[15:0]<63:0>.
hsh_datw[8] is not a thing; As I read CVM_MF_HSH_DAT and CVM_MF_HSH_DATW, they are
different ways of accessing the same data.
hsh_iv[4] is mis-sized; there is no hsh_ivw[]. Similar error wrt DAT?
aes_result/aes_input should be one AESRESINP. You should not invent non-architectural cpu
state. Elsewhere you mention latch/result, but that would be an implementation detail of
individual operations. That said, I don't see any use of aes_input / aes_result that
actually overlap. You copy aes_input to a local variable in[], and write to aes_result
from a local variable out[]. You've already implemented the latch.
Why shared_mode? I don't see anything like it in the docs. From later patches which add
zuc_lfsr[] and snow3g_lfsr[], I think this is incorrect. The docs explicitly say that
those modes overlap HASHDAT[]. You should simply re-use that data.
r~
