Hi,
On 02/12/2013 05:46 PM, Gerd Hoffmann wrote:
On 02/12/13 15:38, Jan Kiszka wrote:
Hi,
was just debugging a memory corruption of my USB driver inside QEMU -
and so far only there:
I have a queue registered with the UHCI controller on an input endpoint
that continuously generates data. At some point my driver decides to
stop reading and removes the QH (with a lot of TDs attached) from the
schedule. The driver waits for the next frame, then releases the QH and
its TDs.
QEMU apparently takes a "few" more frames to consider this queue dead.
In the meantime, it seems to happily fill the TD buffers with data. But
those buffers are long returned to the guest pool of free memory,
causing corruptions there.
Try setting QH_VALID to 1. That should fix it, but has a high chance to
break iso transfers.
I guess we'll need different QH_VALID values depending on transfer type.
Hans? Agree?n
Er, this is tricky. The biggest problem here is that Linux unlinks
and then *relinks* bulk-transfers on UHCI in some cases, and we should not
cancel those, so as much I would like to set QH_VALID to 1, that is not
really an option, as it *will* break Linux guests.
OTOH guests may indeed assume that we stop processing a queue after 1 frame.
The only fix I can think of is allocating a receive buffer inside the UHCI
code for read transfers, and copy the result over to the guest memory when
we are re-scanning the schedule, encounter the completed td and are going
to signal its completion to the guest. Since we then do the write to guest
mem from the schedule scan, that means we won't do it if the qh got unlinked,
but we did not cancel the queue yet, avoiding the memory corruption.
The extra memcpy this introduces should not be a big deal given the low speed
of USB-1, The memory allocations / frees may have some measurable performance
impact, but I think we can live with that.