On Thu, Aug 04, 2022 at 01:43:14PM +0200, Thomas Huth wrote:
On 04/08/2022 12.17, Peter Maydell wrote:
That sounds like we do still have an unbounded-loop problem,
then: there's no limit on the number of consecutive TRBs
we try to read in that function. Maybe we're missing an
error check of some kind (does the spec limit how many
consecutive TRBs there can be somehow?) or else we need
another artificial limit.
I'm not an XHCI expert at all, but while at least having a quick glance at
the spec, I did not see any limit there. So I assume that we should enforce
an artificial limit? What would be a good value for this? Gerd, do you maybe
have any opinion?
Hmm, dunno. Typical workflow is that the driver allocates a page
(or multiple physically contiguous pages) for the TRBs, and when
it reaches the end of the allocation it gets a new block and chains
it using TRB_LINK.
Right now we have a limit for type=TRB_LINK only, having another one for
all TRBs makes sense. The number of TRBs for a transfer can be quite
large (think usb-storage reads/writes), so don't set that too low, 64k
maybe?