Support non-blocking virtqueue management

[ayrtonm]

The virtqueue management done by add_notify_wait_pop function currently spins until the other side uses at least one descriptor buffer and marks it as used. This means there can only be one set of in-flight descriptor buffers at the same time which (1) defeats the point of a queue and (2) limits this crate to use-cases where blocking is acceptable.

Given that there are few options for no_std virtio libraries in the rust ecosystem it would be nice to add support for non-blocking versions of these operations and make use of this in device-specific code as well. @thedataking and I have been maintaining a soft-fork of this crate that adds support for implementing virtio devices and will very likely need to add this feature in the near future (see immunant#14). I'd prefer to add this to virtio-drivers because that may allow us to eventually deprecate our soft-fork and move to a virtio-device crate that instead uses virtio-drivers as a dependency to avoid duplicating code.

I realize this would be an involved change so I want to understand whether the maintainers have considered this/have preferences on how to implement it. I may have time to implement this and make use of it in the vsock driver at some point in the next few months, but I'd like to know if it would be accepted given the complexity it introduces. @qwandor any thoughts?

[qwandor]

I agree that non-blocking options would be good to have in this crate. The challenge is to find an abstraction that is safe, flexible enough that it doesn't force users of the crate to use a particular async model, and ideally doesn't require adding a dependency on alloc to drivers which don't already do so.

There are a couple of drivers which already have non-blocking methods, e.g. VirtIOBlk::read_blocks_nb, but these are unsafe because they rely on the caller not accessing its buffer until it is allowed to do so. I guess we need some abstraction around passing ownership of buffers between the client and the driver, but I don't see a way to do that without heap allocation. Maybe we would just have to make all the non-blocking methods depend on the alloc feature, and say that clients who don't want alloc have to use the blocking methods.

The other question is whether to make these methods async or leave it up to the client to write their own wrappers if they want to. I'm inclined towards the latter, as it looks like implementing async methods would mean tying everything to a specific async runtime. We could consider a separate more opinionated wrapper crate that adds an async runtime dependency though, and I guess would also tie in with interrupt handling somehow.

[qwandor]

All this is to say that I am open to the idea in general, but maybe let's discuss the design you have in mind a bit more before spending too much time implementing it all.