Hi Mark, On Thu, 2026-10-22 at 23:04 +0100, Mark Cave-Ayland wrote: > > > > > > Thanks for the review, but your question made me think about > > openssl, > > and I found a real problem that I didn't see before. Please don't > > apply > > 7/8 and 8/8. > > > > On real hardware, a store to ASI 0xe2 at an aligned address also > > zeroes > > the rest of the block. I measured it: the T4 zeroes the 32-byte > > block, > > the M7 the whole 64-byte line. Other offsets are plain stores. > > > > glibc's niagara4 memset depends on this. For zeroing it only stores > > two of every eight words and lets the hardware clear the rest. QEMU > > does a plain 8-byte store, so with 7/8 and 8/8 a memset(p, 0, n) of > > more than about 120 bytes leaves stale data behind. OpenSSL from a > > Gentoo stage3 crashes at startup because of it. So 7/8 only turns > > the SIGILL into silent corruption. > > > > And then I found a second gap..! > > QEMU rejects the FP form (stda %f, 0xe2), which OpenSSL's T4 AES > > code > > uses for large buffers. OpenSSL probes the CFR itself rather than > > AT_HWCAP, so with only 1-6 and -cpu ...,+vis3,+crypto, AES-CBC/CTR > > on > > large inputs gets SIGILL. SHA and the other instructions work fine > > with > > OpenSSL. > > > > My suggestion: 1-6 can go in as Philippe proposed, since the > > feature > > is opt-in. I'll withdraw 7/8 and 8/8 and send a separate series > > that > > models block-init stores properly (integer and FP, zero-fill as on > > the > > T4), with the hwcap patch on top. I have a memset/memcpy test that > > passes natively on the T4 and catches this, so that series will > > come > > with better testing. > > > > Sorry for the churn, and thanks for asking the right question. > > > > /Stian > > Ack. I'll let this settle overnight as it is getting late here, and > aim to send a PR for patches 1-6 tomorrow evening. >
First of all, thanks for the quick turnaround and friendly attitude towards new contributors. It's really motivating. Was getting late here as well, but fell into a rabbit hole while researching this. AKA long night. Patches 1-6 should be good to send, thanks. As there aren't any other changes, feel free to fix the indentation in patch 4 before sending. For this problem introduced with patch 7 and 8, I tried the most obvious fix, to make the block-init stores behave like a real T4's (essentially zero the blocks in the same way). It worked, but sporadically crashed under my testing. More often with +crypto than without. Checked vs an upstream baseline and determined this was pre- existing. The root cause for the instability is a bug that surfaced more often with +crypto, but isn't caused by it. Traced it to a TCG bug most likely introduced by commit ebf7a5d294a3 (Sept 2025). I can reproduce it deterministically without the series, and I will follow that in a separate thread. So two things need to happen for this series to fully work as intended: 1. A translate.c patch modelling block-init stores. Can send as a follow up if 1-6 goes in. I'm currently testing and validating this thoroughly, and then I would like to send it, so we have a fully working implementation in flight. Not just code that cannot be used. 2. Patch for upstream bug (most likely from ebf7a5d294a3) Separate discussion, outside of this series. I'm still in the validation phase, not trusting my current fixes yet, but hoping to have something concrete to show shortly. /Stian
signature.asc
Description: This is a digitally signed message part
