Re: [PATCH] hw/sd/sdhci: complete non-interrupt ADMA descriptor chains in one pass

Bin Meng <[email protected]> Tue, 4 Aug 2026 19:40:39 +0800
Newsgroups gmane.comp.emulators.qemu.block,gmane.comp.emulators.qemu
Message-ID <CAEUhbmVOkPeMzZGpgJ6WMk07xmf9oGL25jp7uw3uQtPt4LE93g@mail.gmail.com>
Hi Wadim,

On Tue, Aug 4, 2026 at 4:15=E2=80=AFPM Wadim Mueller <[email protected]> wr=
ote:
>
> sdhci_do_adma() processes at most SDHC_ADMA_DESCS_PER_DELAY descriptors
> per invocation and then reschedules itself SDHC_TRANSFER_DELAY ns later
> on QEMU_CLOCK_VIRTUAL.  For a large bulk transfer this spreads the DMA
> across hundreds of virtual-clock round-trips, advancing the guest's
> virtual time between descriptor batches.
>
> A guest that bounds the transfer with its own data/status timeout
> (counted in guest time) can then see that timeout expire mid-transfer.
> Concretely, U-Boot on a TI AM64x reading a ~28 MiB image with a single
> CMD18 multi-block ADMA2 read intermittently aborts with "Timeout for
> status update" and falls back to (failing) distro boot.  The transfer
> itself is correct; only the artificial per-batch pacing triggers the
> guest timeout.
>
> Run a descriptor chain that carries no SDHC_ADMA_ATTR_INT attribute to
> completion within a single call.  Chains that do request a DMA-boundary
> interrupt still deliver it and reschedule exactly as before, so a guest
> relying on that pacing is unaffected.
>
> Now that the per-call bound is gone, cap the number of descriptors
> processed per call so that a malformed or circular descriptor list (a
> self-referencing link, or a persistently faulting non-END/non-INT
> descriptor) cannot spin the calling thread forever; on overflow, break
> to the existing reschedule path so the main loop stays responsive.
>
> Signed-off-by: Wadim Mueller <[email protected]>
> ---
>  hw/sd/sdhci-internal.h |  9 +++++++++
>  hw/sd/sdhci.c          | 23 +++++++++++++++++++++--
>  2 files changed, 30 insertions(+), 2 deletions(-)
>

Would you please try this series to see if this fixes the issue you
saw on TI AM64x?
https://patchwork.ozlabs.org/project/qemu-devel/list/?series=3D515264

Regards,
Bin