[email protected] writes:
> From: Salil Mehta <[email protected]>
>
> The existing 'info hotpluggable-cpus' applies to platforms with true CPU
> hotplug. On ARM, vCPUs are not hotpluggable: resources are allocated at
> boot and policy is enforced administratively (e.g. via ACPI _STA) to
> achieve a hotplug-like effect. As a result, the hotpluggable interface
> cannot describe ARM CPU state, whether administrative or runtime.
>
> Operators need a clear view of both administrative policy (Enabled,
> Disabled, Removed) and guest runtime status (On, Standby, Off, Unknown)
> for all possible vCPUs. This separation is essential to debug CPU life
> cycle flows on ARM, where PSCI CPU_ON/CPU_OFF and ACPI methods are used,
> and to distinguish CPUs that are enumerated but administratively blocked
> from those actually executing in the guest.
>
> The new interface is independent of hotplug and coexists with 'info
> hotpluggable-cpus' on platforms that support it (e.g. x86). By default
> devices are administratively Enabled; on hotpluggable systems, absent
> CPUs appear as Removed here.
>
> This patch introduces:
> * QMP 'query-cpus-powerstate' returning CPUPowerStateInfo per possible
> vCPU.
> * HMP 'info cpus-powerstate' for human-readable output.
> * Enums:
> - CPUPowerAdminState { enabled, disabled, removed }
> - CPUOperPowerState { on, standby, off, unknown }
> * CPUPowerStateInfo with admin/oper state, optional topology ids, and
> qom-path.
>
> Operational state semantics:
> * 'on' : CPU is on and runnable.
> * 'standby' : Reserved for suspend-with-context (e.g. PSCI CPU_SUSPEND).
> Not emitted yet.
> * 'off' : CPU is powered off.
> - At initial boot, admin-disabled vCPUs may be left
> unrealized (lazy realize) and are reported Off.
> - After an admin enable, the vCPU is realized; if later
> powered down, it remains realized and reported Off.
> * 'unknown' : State cannot be determined (very early init/teardown,
> transient hot-(un)plug window, or no power-state handler).
>
> Migration semantics:
> * Admin-disabled (unrealized) vCPUs do not migrate.
> * Admin-enabled vCPUs migrate their operational state, including Off.
>
> Signed-off-by: Salil Mehta <[email protected]>
[...]
> diff --git a/qapi/machine.json b/qapi/machine.json
> index e45740da33..3856785b27 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -1069,6 +1069,93 @@
> { 'command': 'query-hotpluggable-cpus', 'returns': ['HotpluggableCPU'],
> 'allow-preconfig': true }
>
> +##
> +# @CPUOperPowerState:
> +#
> +# Guest-visible operational state of the CPU.
> +# This reflects runtime status such as guest online/offline status or
> +# suspended state (e.g., CPU halted, suspended in a WFI loop).
> +#
> +# .. note::
> +# This field is read-only. It is derived by QEMU from runtime
> +# information (e.g., CPU execution/architectural state, PSCI power
> +# status, vCPU runstate) and cannot be set by management tools or
> +# user commands.
> +#
> +# @on: CPU is online and executing.
> +# @standby: CPU is idle or suspended (e.g., WFI).
> +# @off: CPU is guest-offlined or halted.
> +# @unknown: State cannot be determined at this time (e.g., very early
> +# init/teardown, transient hotplug/hotremove window, no
> +# power-state handler registered, or the target/platform does
> +# not expose a queryable CPU state).
> +##
> +{ 'enum': 'CPUOperPowerState',
> + 'data': ['on', 'standby', 'off', 'unknown'] }
> +
> +##
> +# @CPUAdminPowerState:
> +#
> +# Host-side administrative power state of the CPU device.
> +# Controls guest visibility and lifecycle.
> +#
> +# @enabled: CPU is administratively enabled (can be used by guest)
> +# @disabled: CPU is administratively disabled (guest-visible but unusable)
> +# @removed: CPU is logically removed (not visible to guest)
> +##
> +{ 'enum': 'CPUAdminPowerState',
> + 'data': ['enabled', 'disabled', 'removed'] }
> +
> +##
> +# @CPUPowerStateInfo:
> +#
> +# CPU status combining both administrative and operational/runtime state.
> +#
> +# @id: CPU index
> +# @core-id: Core ID (optional)
> +# @socket-id: Socket ID (optional)
> +# @cluster-id: Cluster ID (optional)
> +# @thread-id: Thread ID (optional)
> +# @node-id: NUMA node ID (optional)
> +# @drawer-id: Drawer ID (optional)
> +# @book-id: Book ID (optional)
> +# @die-id: Die ID (optional)
> +# @module-id: Module ID (optional)
> +# @vcpus-count: Number of threads under this logical CPU (optional)
> +# @qom-path: QOM object path (optional)
> +# @admin-state: Administrative power state (enabled/disabled/removed)
> +# @oper-state: Guest-visible runtime power state (on/standby/off)
> +##
> +{ 'struct': 'CPUPowerStateInfo',
> + 'data': {
> + 'id': 'int',
> + '*core-id': 'int',
> + '*socket-id': 'int',
> + '*cluster-id': 'int',
> + '*thread-id': 'int',
> + '*node-id': 'int',
> + '*drawer-id': 'int',
> + '*book-id': 'int',
> + '*die-id': 'int',
> + '*module-id': 'int',
> + '*vcpus-count': 'int',
> + '*qom-path': 'str',
> + 'admin-state': 'CPUAdminPowerState',
> + 'oper-state': 'CPUOperPowerState'
> + } }
> +
> +##
> +# @query-cpus-power-state:
> +#
> +# Returns all CPUs and their power state info, combining host policy and
> +# runtime guest status. This is useful for debugging vCPU hotplug,
> +# suspend/resume, admin power states or offline state flows.
> +#
> +# Returns: a list of @CPUPowerStateInfo
> +##
> +{ 'command': 'query-cpus-power-state',
> + 'returns': ['CPUPowerStateInfo'] }
> +
> ##
> # @set-numa-node:
> #
Have you considered adding the information to existing query-cpus-fast?
