On Fri, 2020-06-19 at 18:04 -0300, Daniel Henrique Barboza wrote:
> +static void
> +virQEMUCapsSetPPC64KVMState(virQEMUCapsPtr qemuCaps, virArch hostArch)
> +{
> + g_autoptr(virCPUDef) hostCPU = virCPUProbeHost(hostArch);
> +
> + /* At this moment, PPC64 has two KVM modules: kvm_hv and kvm_pr.
> + * QEMU will return KVM present and enabled = true if any of these
> + * is loaded in the host. Thing is, kvm_pr was never officially
> + * supported by IBM or any other distro, but people still ended
> + * up using it in Power8 hosts regardless. It is also currently
> + * unmaintained and broken on Power9, and will be sunset in the
> + * future. kvm_hv is the only KVM module that is and will be
> + * supported.
> + *
> + * Until then, do not claim QEMU_CAPS_KVM if there is only kvm_pr
> + * loaded in the host. There is a good chance that there are
> + * unsupported kvm_pr Power8 guests running in the wild, so let's
> + * cut some slack for this case, for now. */
> + if (STRNEQLEN(hostCPU->model, "POWER8", 6) && !virKModIsLoaded("kvm_hv"))
The macro you're looking for is STRPREFIX() :)
Anyway, the patch overall makes sense to me, but I'm wondering: since
generally we get KVM availability information from QEMU, is libvirt
the right place for this kind of check, or should it rather happen
one layer down the stack so that QEMU reports correct[*] KVM status
information to clients other than libvirt as well? David, what do you
think?
[*] It's fairly questionable whether reporting KVM as not available
when only kvm_pr is loaded is correct. It is certainly helpful,
but correct? Not entirely sure.
--
Andrea Bolognani / Red Hat / Virtualization
