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.
