The following command ends up blocking the device:
host:
while true; do cansend vcan0 134#00; done
guest:
I observe that the device stops to consume descriptors from the rx queue. After debugging, the problem seems the way descriptors from the rx queue are consumed from the available ring. In
|
let requests: Vec<CanDescriptorChain> = vring |
, all the descriptors from the vring are consumed, however, in
|
pub fn process_rx_requests( |
, the number of descriptors used depends on the number of elements in the
rx_fifo_queue. The rest of descriptors are never returned nor used since iter() already incremented the reference in
|
let requests: Vec<CanDescriptorChain> = vring |
. I used Claude to describe the issue:
1. Guest enqueues D1, D2
2. A frame f1 arrives
3. Iter() gets D1, D2
4. Use D1 for F1
5. D2 is never used
Guest is able to reuse those descriptors that are marked as used and added to the used ring but not those that are lost. The situation ends up when there are no more available ring to reuse, which blocks the devices.
Also req_rx_buf is never really used (see
|
let mut req_rx_buf = false; |
).
The following command ends up blocking the device:
host:
guest:
I observe that the device stops to consume descriptors from the rx queue. After debugging, the problem seems the way descriptors from the rx queue are consumed from the available ring. In
vhost-device/vhost-device-can/src/vhu_can.rs
Line 574 in 12667e8
vhost-device/vhost-device-can/src/vhu_can.rs
Line 478 in 12667e8
rx_fifo_queue. The rest of descriptors are never returned nor used since iter() already incremented the reference invhost-device/vhost-device-can/src/vhu_can.rs
Line 574 in 12667e8
Guest is able to reuse those descriptors that are marked as used and added to the used ring but not those that are lost. The situation ends up when there are no more available ring to reuse, which blocks the devices.
Also
req_rx_bufis never really used (seevhost-device/vhost-device-can/src/vhu_can.rs
Line 488 in 12667e8