feat(virtq): add packed virtio ring primitives

[andreiltd]

Add low-level packed virtqueue ring implementation in hyperlight_common::virtq, based on the virtio packed ring format.

This is split from: #1368 and does not include any actual plumbing for guest/host communication.

Useful materials:

• HIP: https://github.com/andreiltd/hyperlight/blob/tandr/rng-rfc/proposals/0001-rng-buf/README.md
• spec: https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-720008
• redhat docs: https://www.redhat.com/en/blog/packed-virtqueue-how-reduce-overhead-virtio

[dblnz]

Great stuff, @andreiltd !
I left a few comments, most are small remarks, others are things I might have missed.
This is part 1 of my review, I still have some things left to look at that I plan on doing tomorrow.

[ludfjig]

This PR is very clean, big fan!

I know we don't really have policy on asserts vs errors etc in hyperlight (I personally like asserts...), but ring.rs has 3 debug_assert! that could be useful in release mode as well, and they're already in methods that return Results. Do you think it makes sense to convert them to errros instead?

[ludfjig]

nit: lot's of map_err lose their context when going to RingError::MemError, maybe can parametrize RingError<E> on generic E which is some M::Error? Not sure, feel free to ignore

[andreiltd]

I tried this initially yes, and make it generic creates much more API churn especially for the layers on top of virtq. But let me think a bit more how we could preserve context without making ring error generic.

[andreiltd]

I've added more context to the MemError variant:

    #[error("Backend memory error while {op} at address 0x{addr:x}, len {len}")]
    MemError {
        /// Memory operation that failed.
        op: MemOp,
        /// Address passed to the memory backend.
        addr: u64,
        /// Number of bytes requested for the operation.
        len: usize,
    },

I guess the alternative would be to use type erasure like Box<dyn Error> but that will require extra bounds on M::Error: Error + Send + Sync + 'static and will allocate on error path?

[simongdavies]

Great stuff a few minor comments but looks good to me

[simongdavies]

The comments here use the terms "guest" "host" and "device" and "driver" I read the HIP again at https://github.com/andreiltd/hyperlight/blob/tandr/rng-rfc/proposals/0001-rng-buf/README.md#design-details

but still wasn't sure how to interpret these terms here? The HIP suggests that the driver is always the guest and the device is always the host but then goes on to say that for bi-directional communication these roles are reversed , I think it might help us in the future to define explicitly what we are referring to in the code comments.

[andreiltd]

Yes, HIP needs to be updated. Initial version of HIP assumed the roles are swapped depending on direction -- but that idea has been later discarded following allocation discussion in the heap. The most recent agreement is: driver - always a guest, device - always host. I also unified naming here so that it refers to virtio semantics so driver/device.