Live migration
- Radim Krcmar
Analytics
This page is currently undergoing an active discussion. Nothing here is agreed upon.
The RISC-V architecture does not provide good tools for hypervisors to control some observable behavior, mostly related to feature detection in a guest. As a result, a hypervisor cannot easily virtualize the RISC-V architecture, which will complicate migration between different physical micro-architectures.
The gaps on this page are currently not practical issues, because there are no incompatible micro-architectures on the market. The issues are likely to arise when cloud providers start adding a second generation of RISC-V boards to their offerings.
Cloud providers use live migration for maintenance and to optimize hardware utilization.
Amazon EC2 uses live migration when running instances need to be moved from one server to another for hardware maintenance or to optimize placement of instances or to dynamically manage CPU resources. Amazon EC2 Features - Amazon Web Services
Possible solutions
Each possible solution comes with different drawbacks.
Decide that the use-case is not worth supporting.
Provide new ISA extensions.
Redefine DT/ACPI/… to enforce architectural behavior.
Identified gaps
The list might not cover all existing gaps.
senvcfg.PMM
Ssnpm specifies the legal set of values. Any subset is a valid implementation.
Linux currently uses WARL detection to figure out the implemented set: 09d6775f503b ("riscv: Add support for userspace pointer masking").
satp.MODE
The field can be furnished by Sbare, Sv39, Sv48, Sv57, and custom/future extensions, like Sv64.
Default Linux currently uses WARL detection and tries Sv57, Sv48, and Sv39, in that order: 011f09d12052 ("riscv: mm: Set sv57 on defaultly").
satp.ASID
The number of ASID bits is unspecified.
Linux currently uses WARL detection and uses the maximum amount of bits: 65d4b9c53017 ("RISC-V: Implement ASID allocator").
Related content
RISC-V International