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?

[simongdavies]

Great stuff a few minor comments but looks good to me

[ludfjig]

LGTM, not sure if you saw this comment but not blocking

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?

[danbugs]

Only minor NITs. Really great work, @andreiltd !

[andreiltd]

LGTM, not sure if you saw this comment but not blocking

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?

Hey @ludfjig, sorry - there were few back and forth with usage of asserts so I thought I already addressed that - we had CI checks that banned usage of assert macro at some point but that has been now relaxed. I converted the asserts in question into invalid state errors - I think it makes sense for dealing with malicious driver. Thanks for pointing that out!

032ac0b

[dblnz]

Great work! I have nothing else to add.