the stub "VirtioNetDriver" for the in-Propolis virtio-net tests really only covers the control interface for a NIC. it sets up some rings and then does not use them at all.
I punted on figuring out moving data on the rings because I wasn't sure how we'd observe device interrupts in this context - there's technically a VM, so it could receive interrupts, but the plumbing for a VM to get an interrupt and then poke an I/O port or something for the test harness to be told about the interrupt.. seems bad.
instead of doing .. whatever that would be .. we can probably just pretend it's a poll-mode driver and have a Rust thread that spins looking at rings to tell when progress happens. that at least lets us write tests covering device I/O, and if we switch out how we find out about activity in the future the tests might not need to change!
the stub "
VirtioNetDriver" for the in-Propolis virtio-net tests really only covers the control interface for a NIC. it sets up some rings and then does not use them at all.I punted on figuring out moving data on the rings because I wasn't sure how we'd observe device interrupts in this context - there's technically a VM, so it could receive interrupts, but the plumbing for a VM to get an interrupt and then poke an I/O port or something for the test harness to be told about the interrupt.. seems bad.
instead of doing .. whatever that would be .. we can probably just pretend it's a poll-mode driver and have a Rust thread that spins looking at rings to tell when progress happens. that at least lets us write tests covering device I/O, and if we switch out how we find out about activity in the future the tests might not need to change!