aarch64 Support #198
Description
This issue tracks aarch64 support.
I am working on an experimental implementation of aarch64 support for Rust Hypervisor Firmware.
The code is available at:
- QEMU aarch64 virt: https://github.com/retrage/rust-hypervisor-firmware/tree/aarch64-virt-support
- Cloud Hypervisor: https://github.com/retrage/rust-hypervisor-firmware/tree/aarch64-ch-support
Current Status
The changes in this branch have been tested to work using QEMU aarch64 virt.
Similar to x86_64, you can boot the Linux image by specifying the firmware with -kernel. The major changes are as follows:
- Add target and linker scripts for aarch64.
- Add
BootInfofor FDT. - Support for PCI configuration space access using MMIO on aarch64
- Add virtio-mmio driver (only for QEMU)
I will propose these changes in multiple PRs.
To-Do
[ ] Implement remapping of EFI runtime services- Add initial CH support
- Split architecture dependent code for multiple architecture support (build: Split x86_64 specific code #203)
- Improve EFI compatibility for aarch64/Linux boot (efi: Improve EFI Compatibility #204)
- Add initial aarch64 support (arch: Add aarch64 support #205)
- Add testing (arch: Add aarch64 support #205)
- Add CI builds (arch: Add aarch64 support #205)
- Support vanilla Ubuntu cloud images (AArch64: let ubuntu 20.04+ boot from rust hypervisor firmware #262)
- Add integration testing (tests: Add integration tests for aarch64 #267)
- Update documents
Known Issues
This aarch64 support has the following issues.
Cloud Hypervisor is not yet supported.
This aarch64 support does not yet support Cloud Hypervisor. This is because I do not have an aarch64 machine that supports GICv3 or later and cannot test it. Please let me know if there is a good test environment available.
Update: It works with a custom Ubuntu bionic cloud image.
objcopy is required as post-processing after build.
QEMU aarch64 virt has an emulator loader that behaves differently depending on the type of binary passed with -kernel. When the binary is not ELF, QEMU executes the binary with the first address of the FDT passed in the x0 register. You need to run objcopy as a post-processing step to convert it to raw binary, as follows:
This post process is not needed by generating as a raw binary at link time. See eaed071.
Run QEMU with the binary as follows:
qemu-system-aarch64 \
-machine virt \
-cpu cortex-a53 \
-m 8G \
-nographic \
-serial mon:stdio \
-drive id=disk,file=$(AARCH64_IMG),if=none \
-device virtio-blk-pci,drive=disk,disable-legacy=on \
-kernel target/aarch64-unknown-none/debug/hypervisor-fw