I tested something similar, I tried to load data at address 0xXXXXXXX1 using lxvd2x and it loaded it properly.
On Tue, Jun 30, 2020 at 12:35 PM Jeffrey Walton noloader@gmail.com wrote:
On Tue, Jun 30, 2020 at 5:29 AM Jeffrey Walton noloader@gmail.com wrote:
On Tue, Jun 30, 2020 at 5:14 AM Maamoun TK maamoun.tk@googlemail.com
wrote:
Patch implementation benchmark for GCM_AES (Tested on POWER8): little-endian:
- Encrypt x~17.5 of nettle C implementation
- Decrypt x~17.5 of nettle C implementation
- Update x~30 of nettle C implementation
big-endian:
- Encrypt x~18.5 of nettle C implementation
- Decrypt x~18.5 of nettle C implementation
- Update x~28.5 of nettle C implementation
...
One small comment for aes_encrypt and aes_decrypt... src and dst are usually user supplied buffers. Using lxvd2x to load a vector may produce incorrect results if the user is feeding a stream to an encryptor or decryptor that is not naturally aligned to that of an unsigned int. (On the other hand, Nettle controls the round keys array so lxvd2x should be fine.)
Instead of lxvd2x and friends for the user's buffers you should consider using lvx and doing the lvsl thing to fix the data in the registers.
In fact, you might want to add a test case like this:
uint8_t plain[19] = {0,1, ..., 17, 18}; uint8_t cipher[16], recover[16];Then send plain, plain+1, plain+2 and plain+3 into the encryptor and see if it round trips. lxvd2x will choke even on POWER9 because two of the tests will not even be naturally aligned for a byte.
Jeff