On Thu, Jun 25, 2026 at 14:12:22 +0100, Chris Riches via Devel wrote:
> From: Chris Riches <[email protected]>
> 
> Ever since commit 3fc4412c6f (qemu: support kvm-poll-control performance
> hint) introduced support for kvm-poll-control, libvirt has only emitted
> the arg when it is explicitly enabled. However, leaving the arg missing
> from the output is not equivalent to disabling it, since QEMU may
> default it to `on` in certain paths (for example, with `-cpu host`).
> 
> Therefore, if the XML specifies state='off', we should explicitly set
> that to ensure it is disabled in qemu.
> 
> Signed-off-by: Chris Riches <[email protected]>
> ---
>  src/qemu/qemu_command.c                                   | 7 +++++--
>  tests/qemuxmlconfdata/kvm-features-off.x86_64-latest.args | 2 +-
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index e726dc661c..dbc4b5ac94 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -6745,8 +6745,11 @@ qemuBuildCpuCommandLine(virCommand *cmd,
>                  break;
>  
>              case VIR_DOMAIN_KVM_POLLCONTROL:
> -                if (def->kvm_features->features[i] == VIR_TRISTATE_SWITCH_ON)
> -                    virBufferAddLit(&buf, ",kvm-poll-control=on");
> +                if (def->kvm_features->features[i]) {

Make this an explicit comparison:

def->kvm_features->features[i] !=  VIR_TRISTATE_SWITCH_ABSENT

> +                    virBufferAsprintf(&buf, ",kvm-poll-control=%s",
> +                                      def->kvm_features->features[i] ==
> +                                      VIR_TRISTATE_SWITCH_ON ? "on" : "off");

And this can use virTristateSwitchTypeToString instead of a hardcoded
string conversion.


One unfortunate thing is that this can break guest ABI. The ABI
stability check 'virDomainDefFeaturesCheckABIStability' is correctly
rejecting it but if we generate a config from an XML using the '_OFF'
variant but the default was _ON the ABI will change.

Do you know if there is a possibility to probe the current state from a
running VM? If yes we'll likely have to reconcile the state from the
running VM so that this doesn't happen once we start to honour the
'_OFF' state explicitly.

If there is a way to detect it it will need to go somewhere into the
reconnection code path.

Reply via email to