On 29/06/2026 13:47, Peter Krempa wrote:
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.
Thanks, will make those improvements.
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.
Ah, I hadn't considered the ABI. Is the following understanding of the
problem correct?
1. If the XML had an explicit poll-control=off but QEMU had actually
enabled it under the hood, then we upgrade libvirt, then do something
like a save+restore, the restore will actually force poll control off
and break the ABI.
2. If we are in the same libvirt-qemu mismatch, and do not upgrade
libvirt but instead migrate the VM to a remote host that has already
upgraded libvirt, then the incoming migration will have the same ABI
breakage.
The first case sounds solvable by new logic in the reconnect path as you
suggest, but the second case sounds much harder to solve, since the
source libvirt doesn't know how to tell the destination one about the
mismatch.
Have I understood that correctly, and do you have any ideas about how to
resolve this?
- Chris
