KVM's treatment of the ID registers that describe the implementation (MIDR, REVIDR, and AIDR) is interesting, to say the least. On the userspace-facing end of it, KVM presents the values of the boot CPU on all vCPUs and treats them as invariant. On the guest side of things KVM presents the hardware values of the local CPU, which can change during CPU migration in a big-little system. While one may call this fragile, there is at least some degree of predictability around it. For example, if a VMM wanted to present big-little to a guest, it could affine vCPUs accordingly to the correct clusters. All of this makes a giant mess out of adding support for making these implementation ID registers writable. Avoid breaking the rather subtle ABI around the old way of doing things by requiring opt-in from userspace to make the registers writable. When the cap is enabled, allow userspace to set MIDR, REVIDR, and AIDR to any non-reserved value and present those values consistently across all vCPUs.
Showing the changes to include/uapi/linux (1 of 6 files). Show all
Unified · Split
| @@ -929,6 +929,7 @@ struct kvm_enable_cap { · 928 unmodified lines | |||
| 929 | #define KVM_CAP_PRE_FAULT_MEMORY 236 | 929 | #define KVM_CAP_PRE_FAULT_MEMORY 236 |
| 930 | #define KVM_CAP_X86_APIC_BUS_CYCLES_NS 237 | 930 | #define KVM_CAP_X86_APIC_BUS_CYCLES_NS 237 |
| 931 | #define KVM_CAP_X86_GUEST_MODE 238 | 931 | #define KVM_CAP_X86_GUEST_MODE 238 |
| 932 | #define KVM_CAP_ARM_WRITABLE_IMP_ID_REGS 239 | ||
| 932 | 933 | ||
| 933 | struct kvm_irq_routing_irqchip { | 934 | struct kvm_irq_routing_irqchip { |
| 934 | __u32 irqchip; | 935 | __u32 irqchip; |