> On 7 Jul 2026, at 2:31 PM, Sandesh Patel <[email protected]> wrote: > > From: Sandesh Patel <[email protected]> > > Hi, > This RFC series adds libvirt support for ARM CPU features that are > exposed by QEMU as multi-valued properties, rather than the on/off > booleans we are used to from x86. > > Background > ========== > On ARM, several CPU properties can take one of a small set of > values (e.g. "0.0", "1.0", "1.1_base", "off"), and the set > of values supported by each property is host-specific. This cannot > be expressed using libvirt's existing boolean feature model. > This series depends on a pending QEMU RFC [1] that introduces > non-boolean feature handling for ARM CPUs. That series also adds a > new QMP command, query-arm-cpu-props-info, which reports the values > the host accelerator supports for each ARM CPU property. Example > reply fragment: > { > "name": "hw_prop_WRPs", > "supported-values": ["0-3"], > "type": "number" > } > On top of that QEMU work, this libvirt RFC wires up the end-to-end > flow: probing the host, caching the probed information, exposing > the values in the guest CPU XML, and passing them through to the > QEMU -cpu command line. > I am posting this as an RFC primarily to get maintainer feedback on > the overall approach before investing in the missing pieces (in > particular, value validation, which is intentionally not yet > implemented). See "Open questions" below. > > Overview of the series > ====================== > 1. Add a QMP wrapper for query-arm-cpu-props-info, a new > QEMU_CAPS_QUERY_ARM_CPU_PROPS_INFO capability bit, and the > qemuMonitorCPUPropsInfoList data structure. The command is > issued on ARM + KVM hosts and the reply is stored in the > per-accelerator capabilities. > 2. Persist the probed list into the on-disk QEMU capabilities > cache as <cpuPropertyInfo>, so that subsequent libvirtd > restarts do not need to re-issue the QMP query. > 3. Extend the guest CPU XML with an optional 'value' attribute > on <feature>: > <cpu mode='host-passthrough'> > <feature policy='require' name='feat_RAS' value='1.0'/> > <feature policy='require' name='hw_prop_API' value='off'/> > <feature policy='require' name='hw_prop_WRPs' value='2'/> > </cpu> > When a feature carries a non-NULL 'value', libvirt emits > '<name>=<value>' on the QEMU -cpu command line; in that case > the policy must be 'require' or 'force'. The existing > policy-driven '=on' / '=off' path is used only for features > without an explicit value. > All ARM property names returned by query-arm-cpu-props-info > are registered in src/cpu_map/arm_features.xml so that the > guest XML parser and validator accept them. > With this change, the generated QEMU command line can look > like: > -cpu host-passthrough,hw_prop_API=off,hw_prop_WRPs=2 > > Changes since v1: > ================ > - Split the single "query" patch so the new capability bit is added in > its own patch, separate from the code that uses it. > - The capability dump is now captured from a real QEMU (built with the > pending ARM series and probed with qemucapsprobe on a KVM host) > instead of being edited by hand. It is added as a separate > "+armcpuprops" variant > > Open questions > ============== > - Value validation: should libvirt validate the requested value > against the host's supported-values list at define time, at > start time, or defer entirely to QEMU? > - Policy vs. value conflicts: is requiring policy='require' / > 'force' whenever 'value' is set the right rule? > - Caching location: is the per-accelerator QEMU capabilities > cache the right place to store the probed property list, or > should this live alongside the CPU model data in cpu_map? > > Sandesh Patel (5): > Add QEMU_CAPS_QUERY_ARM_CPU_PROPS_INFO > Add support to query ARM CPU property values > Cache and load ARM CPU property information > Add '+armcpuprops' capability variant for query-arm-cpu-props-info QMP > Support 'value' attribute on CPU features > > src/conf/cpu_conf.c | 21 +- > src/conf/cpu_conf.h | 1 + > src/conf/schemas/cputypes.rng | 5 + > src/cpu_map/arm_features.xml | 171 + > src/qemu/qemu_capabilities.c | 130 +- > src/qemu/qemu_capabilities.h | 1 + > src/qemu/qemu_command.c | 13 + > src/qemu/qemu_monitor.c | 52 + > src/qemu/qemu_monitor.h | 26 + > src/qemu/qemu_monitor_json.c | 66 + > src/qemu/qemu_monitor_json.h | 5 + > .../qemu_11.1.0-virt.aarch64+armcpuprops.xml | 357 + > .../qemu_11.1.0.aarch64+armcpuprops.xml | 357 + > .../caps_11.1.0_aarch64+armcpuprops.replies | 40506 ++++++++++++++++ > .../caps_11.1.0_aarch64+armcpuprops.xml | 1436 + > .../caps.aarch64+armcpuprops.xml | 28 + > tests/qemumonitorjsontest.c | 91 + > ...res-values.aarch64-latest+armcpuprops.args | 34 + > ...ures-values.aarch64-latest+armcpuprops.xml | 46 + > .../aarch64-cpu-features-values.xml | 30 + > tests/qemuxmlconftest.c | 2 + > tests/testutilshostcpus.h | 74 +- > 22 files changed, 43411 insertions(+), 41 deletions(-) > create mode 100644 > tests/domaincapsdata/qemu_11.1.0-virt.aarch64+armcpuprops.xml > create mode 100644 tests/domaincapsdata/qemu_11.1.0.aarch64+armcpuprops.xml > create mode 100644 > tests/qemucapabilitiesdata/caps_11.1.0_aarch64+armcpuprops.replies > create mode 100644 > tests/qemucapabilitiesdata/caps_11.1.0_aarch64+armcpuprops.xml > create mode 100644 tests/qemucaps2xmloutdata/caps.aarch64+armcpuprops.xml > create mode 100644 > tests/qemuxmlconfdata/aarch64-cpu-features-values.aarch64-latest+armcpuprops.args > create mode 100644 > tests/qemuxmlconfdata/aarch64-cpu-features-values.aarch64-latest+armcpuprops.xml > create mode 100644 tests/qemuxmlconfdata/aarch64-cpu-features-values.xml > > -- > 2.43.7 >
Hi everyone, Sending a follow-up review request regarding the RFC v2 patch series. Since this is an RFC, my main goal is to ensure the high-level approach aligns with libvirt's architecture before finalizing the implementation. I’d appreciate any feedback on: 1. The overall design and structural approach. 2. Any potential concerns with the proposed API or XML changes. Best regards, Sandesh
