Skip to content
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

Add kvm guest memfd related capabilities #288

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

KeyboardNerd
Copy link

Summary of the PR

The capabilities are required to properly setup a guest_memfd to provide better host and guest memory isolation. The memory attributes capability returns an integer with each bits representing different configs. For example, the return integer & KVM_MEMORY_ATTRIBUTE_PRIVATE > 0 means the vm is capable of setting memory pages to private.

Requirements

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

  • All commits in this PR have Signed-Off-By trailers (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.

The capabilities are required to properly setup a guest_memfd to provide better
host and guest memory isolation. The memory attributes capability returns an
integer with each bits representing different configs. For example, the return
integer & KVM_MEMORY_ATTRIBUTE_PRIVATE > 0 means the vm is capable of setting
memory pages to private.

Signed-off-by: Sida Chen <[email protected]>
Signed-off-by: Sida Chen <[email protected]>
Signed-off-by: Sida Chen <[email protected]>
Signed-off-by: Sida Chen <[email protected]>
@KeyboardNerd
Copy link
Author

It's a continued discussion from
#284
I accidentally closed that one :(

Copy link
Contributor

@TimePrinciple TimePrinciple left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this work! While I think you could still reopen a PR if you accidentally closed one, if you still have that branch :) Thus we could avoid throwing out PRs

And could you squash 741fb48, 2523d68, 7283cc6 and 3778efe altogether, otherwise we would break bistability along the way 🙂

Comment on lines +2557 to +2562
#[test]
fn test_check_extension_int() {
let kvm = Kvm::new().unwrap();
let vm = kvm.create_vm().unwrap();
assert!(vm.check_extension_int(Cap::MpState) > 0);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since test_check_extension_raw exists, in my view test_check_extension_int is not necessary, it's just a wrapper on check_extension_raw. This test is just duplicating existing code :)

fn test_check_extension_raw() {
let kvm = Kvm::new().unwrap();
let vm = kvm.create_vm().unwrap();
assert!(vm.check_extension_raw(Cap::MpState as c_ulong) > 0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMHO this is literally a check_extension test which gets expanded, if we intend to test check_extension_raw positively, we can do something like assert_eq!(vm.check_extension_raw(Cap::MaxVcpus), 1024); here to state that we want an int which its value matters.

Or else we just do negative test here :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1024 here is for RISC-V, as of the other two archs, we will need to set its value accordingly

/// use kvm_ioctls::Cap;
///
/// let kvm = Kvm::new().unwrap();
/// assert!(kvm.check_extension_raw(Cap::MaxVcpus as c_ulong) > 0);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the wrong function to call here, as it does the system-wide extension check, instead of the VM-level extension check. If you fix this, you can also remove the unittest you added, because they're the same as these doctests :)

/// ```
/// extern crate kvm_bindings;
///
/// # use kvm_bindings::{KVM_MEMORY_ATTRIBUTE_PRIVATE};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for this import, since the final version of the code is checking the MaxVcpus capability

@roypat
Copy link
Collaborator

roypat commented Oct 14, 2024

Could you also squash all the commits into one?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants