On Fri, Jul 10, 2020 at 7:48 AM Mark Mielke <mark.mielke(a)gmail.com> wrote:
On Fri, Jul 10, 2020 at 7:14 AM Jiri Denemark
<jdenemar(a)redhat.com> wrote:
> > + if (qemuCaps &&
>
> + def->cpu->mode == VIR_CPU_MODE_HOST_PASSTHROUGH &&
> > + !def->cpu->migratable) {
> > + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_MIGRATABLE))
> > + def->cpu->migratable = VIR_TRISTATE_SWITCH_ON;
> >
> > *+ else if (ARCH_IS_X86(def->os.arch))+
> > def->cpu->migratable = VIR_TRISTATE_SWITCH_OFF;*
> > + }
>
> The implementation seems to be doing exactly what the commit message
> says. The migratable=off default should be used only when QEMU does not
> support -cpu host,migratable=on|off, that is only when QEMU is very old.
> Every non-ancient version of libvirt should have the
> QEMU_CAPS_CPU_MIGRATABLE set and thus this code should choose
> migrateble=on default.
>
I wasn't sure what QEMU_CAPS_CPU_MIGRATABLE represents. I initially
suspected what you are saying, but since it apparently did not work the way
I expected, I then presumed it does not work the way I expected. :-)
Is QEMU_CAPS_CPU_MIGRATABLE only from the <cpu> element? If so, doesn't
this mean that it is not explicitly listed for host-passthrough, and this
means the check is not detecting whether it is enabled or not properly?
Trying to understand what is going on more - I see "migratable" seems to be
ok when launching a new machine, but the failure scenario was live
migration from 6.4.0 to 6.5.0.
Is this because the QEMU_CAPS_CPU_MIGRATABLE was not filled in for 6.4.0,
and live migration grabs the capabilities from the source, where the
absence of this capability makes it presume an older Qemu in the above code?
--
Mark Mielke <mark.mielke(a)gmail.com>