Obtain a successful cargo build --target aarch64-unknown-linux-musl.
This implies (but it is not limited to):
Identify and label accordingly x86_64 specific code.
Label the wrappers over the kvm ioctls in conformity with Oficial KVM API.
Code inside the kvm_gen/src/x86_64/bindings.rs is not actually x86_64 specific. The auto generated bindings contain a common wrapper as it is autogenerated from include/uapi/linux/kvm.h and you may also find variables like KVM_PPC_PVINFO_FLAGS_EV_IDLE which are power pc related. Get rid of the x86_64 classification inside this crate.
The default syscalls that the vmm uses are diferent on an aarch64. For example, arm does not use libc::SYS_open but libc::SYS_openat. Indeed, compare the arch/aarch64/bits/syscall.h inside the musl repo with its x86_64 equivalent (i.e arch/x86_64/bits/syscall.h).
Not necessarily a blocker for succesful aarch64 compilation, but we are using#[cfg(any(target_arch = "x86", target_arch = "x86_64"))] mistakenly throughout our code. Firecracker would not actually compile on an x86 (see timestamp_cycles() function inside fc_util crate.
Building with aarch64-unknown-linux-musl is not currently possible. See rust issue. See if workaround suggested works.
dianpopa
commented
5 years ago
Obtain a successful
cargo build --target aarch64-unknown-linux-musl. This implies (but it is not limited to):x86_64specific code.kvm_gen/src/x86_64/bindings.rsis not actuallyx86_64specific. The auto generated bindings contain a common wrapper as it is autogenerated frominclude/uapi/linux/kvm.hand you may also find variables likeKVM_PPC_PVINFO_FLAGS_EV_IDLEwhich are power pc related. Get rid of thex86_64classification inside this crate.libc::SYS_openbutlibc::SYS_openat. Indeed, compare thearch/aarch64/bits/syscall.hinside the musl repo with its x86_64 equivalent (i.earch/x86_64/bits/syscall.h).#[cfg(any(target_arch = "x86", target_arch = "x86_64"))]mistakenly throughout our code. Firecracker would not actually compile on anx86(seetimestamp_cycles()function insidefc_utilcrate.