Hello Longfang and all,

Thank you for the suggestion. I tested the alignment hypothesis on the affected system with an
instrumented HPRE module built against the exact 7.0.14-6-pve headers.

The diagnostic patch detects in-place or unaligned RSA requests and routes source and destination
through separate dma_alloc_coherent() buffers. Per-PF counters prove that this path was used.

Results:

  0000:3e:00.0: send=250, recv=250, bounce=250
  0000:3a:00.0: send=250, recv=250, bounce=250
  0000:7e:00.0: send=250, recv=250, bounce=250
  0000:7a:00.0: first request hung, send=1, recv=0, bounce=1

For the failing PF:

  SEND_SQE_TO_ACC=1, ACC_FINISH=1, CQE_OUT=1, EQE_OUT=1
  Linux completion IRQ count=0, HPRE recv_cnt=0

The task remained blocked in rsassa_pkcs1_verify(), at the same point as the original incident.
Thus, in-place and unaligned buffers are present, but separate coherent bounce buffers do not fix
the deterministic completion loss on 0000:7a:00.0. Alignment is not a sufficient root cause. The
new evidence narrows the fault to the completion-notification path after accelerator completion
and before the HPRE response callback.

Could you please help clarify:

1. What are the exact meanings of QM_DFX_ACC_FINISH_CNT, QM_CQE_OUT, and QM_EQE_OUT?
2. With ACC_FINISH=1, CQE_OUT=1, EQE_OUT=1, and Linux IRQ=0, which additional QM/HPRE/GIC ITS
   registers would be most useful?
3. Is there a known revision-30 19e5:a258 issue affecting one PF/NUMA node or its MSI path?
4. Is there a safe way to poll/recover the affected CQ/QP and complete the request with an error
   while preventing a late-callback use-after-free?

I attached the complete report, experiment patch, and a sanitized evidence archive containing
four-PF counters, QM/PCI/MSI state, raw IRQ counts, and the blocked-task stack. The archive contains
no management addresses, credentials, serial numbers, or unrelated logs.

Attachment SHA-256:

  report: 610f08baf93177b0069a406c55279ed73fc1e9cd417ce64c813d8e29fa0e2108
  patch:  811332a88a7338cc144b60268d9e9be4bae233ce6a0fdab587bead29ceacec50
  data:   42567764d09204758b0f5e01c9b4d93fab4ed0d2a1a15afef64803d8b7c74815

The host is back on the safe baseline with hisi_hpre blacklisted and rsa-generic selected. A
200-cycle signed-module verification test across all four NUMA nodes passed after recovery.

Regards,
Evanshenf
GitHub: https://github.com/Evanshenf