Hi,
On 21/9/26 14:32, Khushit Shah wrote:
Hi All,
Here is v4 of the RFC for named CPU models on Arm64/KVM.
Background:
=============================================================
Currently QEMU only supports -cpu host/max for KVM on Arm64. This blocks
live migration of VMs between hosts that differ in CPU features.
This RFC proposes hierarchical named models for Arm64 under KVM. A named
model is a strict contract of the CPU features exposed to the guest, so
the same model resolves to the same guest-visible ID registers on any
capable host. Models can be customized further by overriding individual
ID-register fields (e.g. SYSREG_ID_AA64ISAR0_EL1_SHA1=0).
On top of the models, this series adds the QMP introspection support on
Arm that the management layer already depends on for x86:
`query-cpu-definitions` lists the models a host can run and reports
blockers for the ones it cannot, `query-cpu-model-expansion` resolves a
model to its full set of properties, and the new `query-cpu-props-info`
reports the values the host supports for each property. The aim is feature
parity with x86 so existing tooling can consume Arm named models with
little change.
TL;DR examples:
=============================================================
# Boot a named model
qemu-system-aarch64 -cpu grace-v1 -machine virt,accel=kvm ...
# Named model with ID-register field override
qemu-system-aarch64 -cpu grace-v1,SYSREG_ID_AA64ISAR0_EL1_SHA1=0 ...
# -cpu host with ID-register field override
qemu-system-aarch64 -cpu host,SYSREG_ID_AA64ISAR0_EL1_AES=1 ...
# query-cpu-model-expansion
"model": {
"name": "graviton4-v1",
"props": {
"SYSREG_ID_AA64ISAR0_EL1_AES": 2,
"SYSREG_ID_AA64ISAR0_EL1_SHA1": 1,
"SYSREG_ID_AA64ISAR0_EL1_SHA2": 2,
"SYSREG_ID_AA64ISAR1_EL1_APA": 3,
"SYSREG_ID_AA64PFR0_EL1_SVE": 1,
"sve": true,
"sve128": true,
...
}
}
Khushit Shah (25):
target/arm: expose SYSREG_ props for REVIDR_EL1 and AIDR_EL1
target/arm: expose all non-res ID reg fields as properties
target/arm: move SYSREG_ prop infra to cpu64.c
target/arm/kvm: enable writable implementation ID registers
target/arm/kvm: read all ID registers from KVM
target/arm/kvm: handle special ID registers when reading from KVM
target/arm/kvm: process ID register writeback per field
target/arm/kvm: handle writeback for special ID register fields
While the first part of this series do KVM specific calls to get
usable ID registers, the rest doesn't seem KVM specific. IOW, what
would restrict named CPU models to be used with HVF or WHPX? IIUC
as long as we can validate the CPU features with the host we are
good. If so, some handlers should be moved to the accelerator layer;
but of couse this can be done later.
target/arm: introduce named CPU model infrastructure
target/arm: fix SVE and PAuth finalize for named CPU models
target/arm: disable PMU support for named CPU models
target/arm: add arm-v9.0-a-v1 named CPU model
target/arm: add neoverse-v2-v1 named CPU model
target/arm: add neoverse-v2-v2 named CPU model
target/arm: add graviton4-v1 named CPU model
target/arm: add grace-v1 named CPU model
target/arm: fail named CPU models on unknown non-zero feature ID regs
target/arm: add cpu-models-stub.c
target/arm/qmp: allow named CPU models on cpu-model-expansion
target/arm/kvm: compute host-supported values for ID register fields
target/arm: report 0 as supported for ID fields gated by vCPU init
flags
target/arm/kvm: add kvm_arm_get_host_isar helper
qmp: add query-cpu-props-info command
target/arm/qmp: implement query-cpu-props-info for KVM
target/arm/qmp: hook blockers in query-cpu-definitions
