-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xen/mmapv2 #160
Xen/mmapv2 #160
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vireshk I have not found anything that jumped to my eye. However, I find it a bit hard to follow what is happening. I think a bit more detail in the commit messages and a few more details in the doc strings could be helpful to follow what happens here :).
6451854
to
2ae109d
Compare
Waiting for rust-vmm/vm-virtio#250 to get merged. |
a863253
to
c65ea35
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just some nit-picking...
Fixes: #169 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thing that is not clear to me is: if we enable xen
then we will always only handle xen guests, and we could never have the case of handling both?
If this is the case, then we should document this compile-time feature like: if you enable it you can only handle xen guests.
This is based on the decision taken in the vm-memory crate. In the very first version, I tried to support both kvm and Xen mappings together in a single build, but that was rejected in favor of simplifying the code and selecting one at compile time only. And so yes, this is either Xen or kvm, but not both currently. Though it may change later, but current code is selected at build time only. Will document this. |
The vm-memory crate now supports Xen specific memory mappings via a special feature: "xen". Add a corresponding feature for vhost crate and add support for Xen memory regions. Update various dependencies to align to the same version of vm-memory crate. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
@stefano-garzarella updated code, hopefully covered all your concerns apart from #160 (comment). |
Automatically enable the VhostUserProtocolFeatures::XEN_MMAP feature for backends for Xen specific builds. With these the backends don't need to enable this feature and can directly support Xen. Suggested-by: Erik Schilling <erik.schilling@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Release a new version with Xen support. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Migrate to a newer version of the vhost and other dependencies and add support for xen memory mappings. Add a corresponding xen feature for vhost-user-backend crate. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Hmm, I have pushed my branch again: https://github.com/vireshk/vhost/tree/xen/mmapv2 , but somehow this pull request isn't fetching the changes automatically anymore. Any idea ? |
Release a new version with Xen support. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Okay, it worked now :) |
vhost: Add support for generic memory mappings
vm-memory crate now supports Xen specific memory mappings via a special
feature: "xen". Modify all vhost crates to work with the new feature.
Signed-off-by: Viresh Kumar viresh.kumar@linaro.org