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