On Tue, May 7, 2024 at 2:52 PM Philippe Mathieu-Daudé <phi...@linaro.org> wrote: > > On 7/5/24 11:43, Mattias Nissler wrote: > > > > > > On Mon, May 6, 2024 at 11:07 PM Mattias Nissler <mniss...@rivosinc.com > > <mailto:mniss...@rivosinc.com>> wrote: > > > > > > > > On Mon, May 6, 2024 at 4:44 PM Peter Xu <pet...@redhat.com > > <mailto:pet...@redhat.com>> wrote: > > > > On Thu, Mar 28, 2024 at 08:53:36AM +0100, Mattias Nissler wrote: > > > Stefan, to the best of my knowledge this is fully reviewed > > and ready > > > to go in - can you kindly pick it up or advise in case there's > > > something I missed? Thanks! > > > > Fails cross-compile on mipsel: > > > > https://gitlab.com/peterx/qemu/-/jobs/6787790601 > > <https://gitlab.com/peterx/qemu/-/jobs/6787790601> > > > > > > Ah, bummer, thanks for reporting. 4GB of bounce buffer should be > > plenty, so switching to 32 bit atomics seems a good idea at first > > glance. I'll take a closer look tomorrow and send a respin with a fix. > > > > > > To close the loop on this: I have posted v9 with patch #2 adjusted to > > use uint32_t for size accounting to fix this. > > "size accounting" calls for portable size_t type. But if uint32_t > satisfies our needs, OK.
To clarify, I'm referring to "bounce buffer size accounting", i.e. keeping track of how much memory we've allocated for bounce buffers. I don't think that there are practical use cases where anyone would want to spend more than 4GB on bounce buffers, hence uint32_t seemed fine. If you prefer size_t (at the expense of using different widths, which will ultimately be visible in the command line parameter), I'm happy to switch to that though.
