Extract vhost-user-backend patches from cloud hypervisor

[arronwy]

This PR extract vhost-user-backend patches from cloud hypervisor: In cloud hypervisor project:

git log --pretty=one vhost_user_backend/ | wc -l
58

Remove dependency crates version upgrade patches:

git log --pretty=one vhost_user_backend/ |grep -i "bump\|cargo\|vmm-sys-util"  | wc -l                                               
20
git log --pretty=one vhost_user_backend/ |grep -i "bump\|cargo\|vmm-sys-util"                                                           
aac87196d6233c17165fff9efc962114b70347e6 build(deps): bump vm-memory from 0.2.0 to 0.2.1
a4bb96d45ce1020f62145bf5f7c056d2117e7a0d build(deps): bump libc from 0.2.70 to 0.2.71
2991fd2a48e449d23e03ba759b12ceffa7beb884 build(deps): bump libc from 0.2.69 to 0.2.70
886c0f9093936d9a37b96f466e1b630e64a208f8 build(deps): bump libc from 0.2.68 to 0.2.69
8acc15a63c1ea094328974f6f2de7cbad4ede1ae build: Bump vm-memory and linux-loader dependencies
51f51ea17dced01a0aad9ba718dcbe68ee0b94ad build(deps): bump libc from 0.2.67 to 0.2.68
f0a3e7c4a1d4641f92737eda8a3b813b24c8c588 build: Bump linux-loader and vm-memory dependencies
5200bf3c59666370d1b17d75022c71c57df2523b Cargo: switch vhost_rs to external crate
f190cb05b5964d844296fac6eb903b51ca17dd97 build(deps): bump libc from 0.2.66 to 0.2.67
3447e226d957acc87fb8109d4b53eaa5ef2b5ab7 dependencies: bump vm-memory from `4237db3` to `f3d1c27`
c61104df475fc73f3b2ca5330f7c3bde9b5ad834 vmm: Port to latest vmm-sys-util
0f21781fbee8de884cbd03c68b625484a8dc3b74 cargo: Bump the kvm and vmm-sys-util crates
ca97385da5ebb7989185e2ff8316643c14818d1f build(deps): bump libc from 0.2.65 to 0.2.66
7498647e3f8eed1f011c6e416b1b075cb75fd980 cargo: Update micro_http
587a420429601dd00ec3358811279b9b99689789 cargo: Update to the latest kvm-ioctls version
de9eb3e0fac36e6c9e48d76fe7c813f8cd057090 Bump vmm-sys-utils to 0.2.0
2d7bfdd92010aca3d6ceae815425d34d089a0765 build(deps): bump libc from 0.2.64 to 0.2.65
3bb51d4d5e881e2da1a2f9f5806b08b07ba4b9b1 build(deps): bump libc from 0.2.62 to 0.2.64
14eb071b291f64f86ffb8244f1a4dd43fd11e580 Cargo: Move to crates.io vmm-sys-util
db151819f1a7f60cc8d9bec7b15b4ec2f7e4e6df Cargo.toml: Add workspace config changes

Remove two reverted patches:

git log --pretty=one vhost_user_backend/ |grep -i "Correct"                                                                          
80c9dc2e0c5cfac8afdf1ffa174f0374f27fe355 Revert "vhost-user-backend: Correct error handling in run"
4a1af7f63c755c54db30b9cc47b2cb86608899ff vhost-user-backend: Correct error handling in run

The final source code have no diff with current cloud hypervisor. The successful cargo build of vhost-user-backend require these two PRs: https://github.com/rust-vmm/vm-virtio/pulls merged into https://github.com/cloud-hypervisor/vm-virtio ch branch and export next_avail/used in Queue struct as pub in vm-virtio :

diff --git a/src/queue.rs b/src/queue.rs
index 280c103..47c736f 100644
--- a/src/queue.rs
+++ b/src/queue.rs
@@ -240,8 +240,8 @@ pub struct Queue {
     /// The maximal size in elements offered by the device
     max_size: u16,

-    next_avail: Wrapping<u16>,
-    next_used: Wrapping<u16>,
+    pub next_avail: Wrapping<u16>,
+    pub next_used: Wrapping<u16>,

     /// The queue size in elements the driver selected
     pub size: u16,

[sameo]

When splitting this kind of crate out of Cloud Hypervisor, we need to find a way to trigger Cloud Hypervisor's CI for each PR that would be sent here.

I'm looking at ways of having repository event dispatches (https://github.com/peter-evans/repository-dispatch) trigger dependabot test PRs. Other ideas?

[sameo]

The successful cargo build of vhost-user-backend require these two PRs: https://github.com/rust-vmm/vm-virtio/pulls merged into https://github.com/cloud-hypervisor/vm-virtio ch branch and export next_avail/used in Queue struct as pub in vm-virtio

@arronwy Could we please first work on steps 1 and 2 from https://github.com/cloud-hypervisor/cloud-hypervisor/issues/1361#issuecomment-649983097 and then have this crate initially pointing at the cloud-hypervisor/vm-virtio crate?

[arronwy]

The successful cargo build of vhost-user-backend require these two PRs: https://github.com/rust-vmm/vm-virtio/pulls merged into https://github.com/cloud-hypervisor/vm-virtio ch branch and export next_avail/used in Queue struct as pub in vm-virtio

@arronwy Could we please first work on steps 1 and 2 from cloud-hypervisor/cloud-hypervisor#1361 (comment) and then have this crate initially pointing at the cloud-hypervisor/vm-virtio crate?

Ok, for step1 split vm-virtio crate into vm-virtio and virtio-devices, should we only submit the changes in cloud hypersor internal project and split vm-virtio directory to vm-virtio and virtio-devices directories? for step 2, Gerry also submit the PR (https://github.com/cloud-hypervisor/vm-virtio/pull/1) to cloud hypervisor vm-virtio ch branch, should we rebase cloud-hypervisor vm-virtio crate on top of Gerry's PR?

[jiangliu]

The vm-virtio dragonball branch is ready for use:)

[arronwy]

Updated Cargo.toml file to use vm-virtion dragonball branch and cargo build succeeded.

[sameo]

@arronwy @jiangliu I think this is ready to be merged as an initial implementation. Please note:

1. There is no CI for this crate yet. @arronwy Could we please at least have github actions running unit and build tests?
2. We won't be able to use that crate from CLH as long as we can't use the upstream vm-virtio design first. See https://github.com/cloud-hypervisor/cloud-hypervisor/pull/1446 as a first step towards that goal
3. We will have to implement a generic mechanism for triggering the CLH CI whenever a PR is sent against this crate, before we can have the CLH code base switch to it.

I'll open issues for items 1 and 3.