Expose VmFd::enable_cap on all architectures

[rogersnm]

Summary of the PR

The KVM_ENABLE_CAP vm ioctl is architecture independent, but both the ioctl definition and VmFd::enable_cap were compiled only for x86_64, s390x and powerpc. This PR removes the cfg gates so they are available on every architecture. The doc example is unchanged as rendered; two hidden doctest lines gate the x86 specific call so the example builds and runs cleanly on every architecture.

Motivation: aarch64 now needs the vm level enable_cap. Linux 6.15 gates writes to the implementation ID registers (MIDR_EL1, REVIDR_EL1, AIDR_EL1) behind KVM_CAP_ARM_WRITABLE_IMP_ID_REGS, which a VMM must enable on the VM before creating any vCPU. Rewriting these registers is how a VMM masks the host CPU identity for guests (the reason the capability exists in KVM), and without enable_cap a VMM has to issue the raw ioctl itself, as Firecracker currently does in firecracker-microvm/firecracker#6116.

Verified: builds and passes clippy and rustfmt on aarch64. The doc example compiles for aarch64 and skips the x86 specific call at runtime; on hosts without /dev/kvm it fails the same way as every other doctest in the crate, so CI coverage is unchanged. The underlying ioctl path (enable the capability, then successfully write MIDR_EL1 via KVM_SET_ONE_REG) was exercised end to end on an EC2 c7g.metal running a 7.0 kernel as part of the Firecracker work linked above.

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. (Covered by the existing doc example, which now compiles and runs on every architecture.)
• 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. (No new unsafe.)

[RuoqingHe]

Codewise looking good, while those changes are already in #344

[andreeaflorescu]

This is the part that is architecture specific I guess.

Is there a capability that we can enable on all platforms? Alternatively, can we define a per platform capability?

[rogersnm]

Thanks for raising this, @andreeaflorescu. I looked into it further and KVM_CAP_HALT_POLL is documented as supporting all architectures and can be enabled through VmFd, making it suitable for this example. I also verified that KVM_CHECK_EXTENSION reports it as supported and that KVM_ENABLE_CAP succeeds on both aarch64 and x86_64.

To remain compatible with older kernels, the example could check for support first:

use kvm_bindings::{kvm_enable_cap, KVM_CAP_HALT_POLL};
use kvm_ioctls::Kvm;

let kvm = Kvm::new().unwrap();
let vm = kvm.create_vm().unwrap();

if kvm.check_extension_raw(KVM_CAP_HALT_POLL.into()) > 0 {
    let cap = kvm_enable_cap {
        cap: KVM_CAP_HALT_POLL,
        args: [100_000, 0, 0, 0],
        ..Default::default()
    };

    vm.enable_cap(&cap).unwrap();
}

Since this PR has now merged, I’m happy to submit this as a small follow-up if you think it would improve the example.

[andreeaflorescu]

Sounds good. Thanks!

[ShadowCurse]

Overall lgtm

[ShadowCurse]

The first # is not needed

[rbradford]

Indeed, please fix.

[rogersnm]

Thanks both, @ShadowCurse and @rbradford. Fixed now by removing the unnecessary leading #, and I’ve rebased the PR onto the latest main.

[rbradford]

Indeed, please fix.

[rbradford]

Thanks!