On Thu, 4 Dec 2025 at 19:34, Jim MacArthur <[email protected]> wrote: > > If both frame and element count are 65535, which appears valid from my > reading of the OMAP5912 documentation, then some of the calculations > will overflow the 32-bit signed integer range and produce a negative > min_elems value. > > Raised by #3204 (https://gitlab.com/qemu-project/qemu/-/issues/3204). > > Signed-off-by: Jim MacArthur <[email protected]> > --- > hw/dma/omap_dma.c | 32 +++++++++++++++++++++----------- > 1 file changed, 21 insertions(+), 11 deletions(-) > > diff --git a/hw/dma/omap_dma.c b/hw/dma/omap_dma.c > index 101f91f4a3..93e6503ff9 100644 > --- a/hw/dma/omap_dma.c > +++ b/hw/dma/omap_dma.c > @@ -504,9 +504,19 @@ static void omap_dma_transfer_setup(struct soc_dma_ch_s > *dma) > struct omap_dma_channel_s *ch = dma->opaque; > struct omap_dma_s *s = dma->dma->opaque; > int frames, min_elems, elements[__omap_dma_intr_last]; > + uint64_t frames64, frame64, elements64, element64; > > a = &ch->active_set; > > + /* > + * We do maths with the frame and element fields which exceeds > + * a signed 32-bit integer, so convert all these to 64 bit for future > use. > + */ > + frames64 = a->frames; > + frame64 = a->frame; > + elements64 = a->elements; > + element64 = a->element;
The real hardware is surely not doing 64-bit arithmetic though. It's presumably working with elements * frames as unsigned 32 bit multiplication. -- PMM
