Cc Stefan & Kevin, for real. On Mon, Oct 26, 2026 at 01:57:42PM -0400, Peter Xu wrote: > On Mon, Oct 26, 2026 at 01:39:58PM +0100, Daniel Gomez wrote: > > On 26/10/2026 13.03, Klaus Jensen wrote: > > > On Oct 26 11:11, Daniel Gomez wrote: > > > > > > I've been holding out on this because I'd really like an Acked-by from a > > > Memory API maintainer (system/dma-helpers.c). > > > > Paolo, Peter, Philippe, > > > > Can you take a look? FYI, patches have already been reviewed by Keith > > and Jesper early last month. > > Sorry for being late, and sorry in advance if I won't follow up this email > as fast.. due to other things occupied. > > Personally I have some uneasy feeling on some changes. It involves > DMAAIOCB, which is not part of what I familiar with QEMU at least before I > read more code.. so please bare with me if I will say something naive. > > It seems to me patch 1/2 tries to fix an issue specific with > qemu_iovec_discard_back(), which I would raise a few questions unanswered > myself: > > - the existing qemu_iovec_discard_back() was introduced back in 2014 in > commit 58f423fbd5, with a mention of fixing > /x86_64/ide/bmdma/short_prdt. Then if patch 1 fixed it up due to some > regression, first question I have is why it wasn't spot by unit test. > Maybe we missed some test? Or others? > > - qemu_iovec_discard_back() alone seems risky on its own, which is the > fundation of this whole series: it directly drop some ranges that we > mapped, which can be bounce buffer. Now, we only fetch bounce buffer > from the raw HVA pointer, which seems fine if we only drop partial and > end of some bounce buffer. But could we drop the whole buffer (causing > bounce buffer leak)? It just seems slightly tricky, after all, the iov > is the only thing dma_blk_unmap() later relies on releasing these > buffers. So if we want to fix this path, I wonder if we can do it even > safer (doesn't mean these patches are bad, so really pure question). > > - for patch 2, it seems to me it's only fixing the case when discard > worked in the middle not at the end. Then IMHO it's a bad idea > splitting two logics: can we somehow put this together with the discard > logic? Would that be cleaner and easier maintainable? > > I added Stefan and Kevin, as this is very block relevant. > > Thanks, > > -- > Peter Xu
-- Peter Xu
