>> correct. >> >> If I have an indirect ring and I'm adding sgs to it and the host is >> delayed (say I've got a thread consuming things from the vring and its >> off doing something interesting), >> I'd really like to get ENOSPC back from virtqueue_add. However if the >> indirect addition fails due to free_sg being 0, we hit the BUG_ON >> before we ever get to the ENOSPC check. > > It is correct for the moment: drivers can't assume indirect buffer > support in the transport. > > BUT for a new device, we could say "this depends on indirect descriptor > support", put the appropriate check in the device init, and then remove > the BUG_ON().
But if the transport has indirect buffer support, can it change its mind at runtime? In this case we have vq->indirect set, but the device has run out of free buffers, but it isn't a case that in+out would overflow it if it had free buffers since it would use an indirect and succeed. Getting -ENOSPC is definitely what should happen from what I can see, not a BUG_ON, I should get a BUG_ON only if the device reports no indirect support. Dave. _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization
