On Tue, Jun 30, 2026 at 13:10:34 +0100, Chris Riches wrote:
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?
Hmm it is indeed tricky. Especially to do somewhat "cleanly". Additional constraint is that we strive to support backward migration (if you start a VM on older libvirt you should be able to migrate it back to it even if it round-trips through new ones). The only thing that comes into my mind is to: 1) document that 'off' isn't really off 2) introduce a new enum value for 'really-off' (obviously with less terrible name 3) keep the behaviour for 'off' introduce explicit disable for 'really-off' That way new libvirt can see which one is used, and old libvirt will behave the same for 'off' and reject 'really-off'. But it is disgusting in the way that 'off' will not mean exactly the same thing as for others and this will be recorded only in the documentation. Optionally a new 'really-on' value could be added and suggested in the docs. Unfortunately anything else akin to adding another attribute or something will not work because old libvirt will ignore it.