Adding POSTCOPY support

[ShadowCurse]

Summary of the PR

Added ability to use VHOST_USER_POSTCOPY_ADVISE, VHOST_USER_POSTCOPY_LISTEN and VHOST_USER_POSTCOPY_END messages. This includes sending them from the frontend and processing them on the backend.

The POSTCOPY messages are only usable when VHOST_USER_PROTOCOL_F_PAGEFAULT feature is negotiated.

Messages and their descriptions are:

• VHOST_USER_POSTCOPY_ADVISE: When the front-end sends this message to the backend, the back-end must open a userfaultfd for later use and send it's fd to the front-end.

• VHOST_USER_POSTCOPY_LISTEN When the back-end receives this message it must ensure that shared memory is registered with userfaultfd to cause faulting of non-present pages. This is always sent sometime after a VHOST_USER_POSTCOPY_ADVISE.

• VHOST_USER_POSTCOPY_END When the back-end receives this message it must disable the userfaultfd. The reply is an acknowledgement only.

Requirements

Before submitting your PR, please make sure you addressed the following requirements:

• [ ] All commits in this PR are signed (with git commit -s), and the commit message has max 60 characters for the summary and max 75 characters for each description line.
• [ ] All added/changed functionality has a corresponding unit/integration test.
• [ ] All added/changed public-facing functionality has entries in the "Upcoming Release" section of CHANGELOG.md (if no such section exists, please create one).
• [ ] Any newly added unsafe code is properly documented.

[Ablu]

@germag: This may be related to your work on migration?

[ShadowCurse]

Hi @Ablu, I have addressed comments you left before, please take another look. Also @vireshk and @germag, would be nice to hear your thoughts as well.

Regarding ci not passing with musl toolchain, I am working on this.

[stefano-garzarella]

@ShadowCurse did you test the changes of rust-vmm-container locally? You can use ./docker.sh build to build a local image and try to build this branch through it.

For example, what I usually do is:

cd rust-vmm-container
./docker.sh build

cd vhost
# I'm using podman, but with docker should be similar
podman run -it --rm --security-opt=seccomp=unconfined --volume $(pwd):/workdir --workdir /workdir localhost/rustvmm/dev:v33_x86_64 
cargo build --target x86_64-unknown-linux-musl

[Ablu]

/cc @stsquad

[ShadowCurse]

@Ablu I have updated the PR to disable postcopy messages if xen feature is enabled. I think this should work for the majority of use cases, while xen + postcopy can be added later if need arises.

[Ablu]

@Ablu I have updated the PR to disable postcopy messages if xen feature is enabled. I think this should work for the majority of use cases, while xen + postcopy can be added later if need arises.

Hm. I must admit that I am not particular thrilled to add further Xen vs non-Xen flags. In fact, I would prefer this way of getting access to virtual addresses altogether as it seems to be confusing.

But I am happy to hear other peoples opinions.

[stefano-garzarella]

nit: I suggest to use imperative form in commit (title and description). https://www.kernel.org/doc/html/v4.10/process/submitting-patches.html#describe-your-changes . And possibly I'd use vhost: and vhost-user-backend: prefix in the title since we have multiple crates in this workspace and that allows us to better understand the git story.

[ShadowCurse]

nit: I suggest to use imperative form in commit (title and description). https://www.kernel.org/doc/html/v4.10/process/submitting-patches.html#describe-your-changes . And possibly I'd use vhost: and vhost-user-backend: prefix in the title since we have multiple crates in this workspace and that allows us to better understand the git story.

Updated commits. Do they look better now?

[stefano-garzarella]

Updated commits. Do they look better now?

Yep, thanks! I'd avoided "can" and used "support", for example: "vhost/frontend: support POSTCOPY messages", but I don't want to be too pedantic, it's fine even as it is now ;-)

BTW the code LGTM, but I'd wait a bit a comment from Viresh and Erik.

[vireshk]

Hi @Ablu, I have addressed comments you left before, please take another look. Also @vireshk and @germag, would be nice to hear your thoughts as well.

Hey, sorry for being late on this. Yeah it is fine for now to disable the feature for Xen builds. That's fine. Thanks.

[stefano-garzarella]

Now that we have tests for the new code, maybe we can enable postcopy for coverage:

diff --git a/coverage_config_x86_64.json b/coverage_config_x86_64.json
index d201e56..9923e17 100644
--- a/coverage_config_x86_64.json
+++ b/coverage_config_x86_64.json
@@ -1,5 +1,5 @@
 {
   "coverage_score": 75.0,
   "exclude_path": "vhost/src/vhost_kern/",
-  "crate_features": "vhost/vhost-user-frontend,vhost/vhost-user-backend"
+  "crate_features": "vhost/vhost-user-frontend,vhost/vhost-user-backend,vhost-user-backend/postcopy"
 }

I tried it locally and the coverage test passes successfully.

[Ablu]

Thanks!