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? take care, Gerd
