[PATCH 2/2] qemu_capabilities.c: drop 'kvm_pr' support for non-Power8 hosts
Daniel Henrique Barboza
danielhb413 at gmail.com
Tue Jun 30 18:33:44 UTC 2020
On 6/30/20 2:35 PM, Andrea Bolognani wrote:
> 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() :)
Thanks!
>
> 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?
>
The reason I did it in Libvirt was to make the tooling and customers aware
that kvm_pr is not officially supported, but at the same time not hinder the
usage of kvm_pr completely for users using it via QEMU command line. People are
still using kvm_pr eventually in niche cases, such as internal tests and
development, specially because hvm_hv does not replace kvm_pr entirely yet
(e.g. kvm_hv does not work in a LPAR).
>
> [*] 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.
Yeah, this is not ideal.
Thing is that, in the Libvirt level, I can cater to customers/tooling and filter
kvm_pr out of the game (i.e. Bugzillas). In QEMU what would happen is either (1) more
people will be impacted and hating my guts because I blocked kvm_pr for unsupported
but valid usage or (2) I would be NACKed in QEMU (I mean, what's the technical reason
for me to claim "kvm_pr is not real KVM"?) and everything will stay as is, everyone
thinking that kvm_pr is usable in both QEMU and Libvirt - and opening bugs - until
kvm_pr is removed.
TBH I don't see any pleasant solution for this kvm_pr situation. Leaving it
as is will keep bugs flowing in until it gets removed, filtering it out under
Libvirt/QEMU is kind of lame and you won't see me denying it. This patch is not
my finest hour, that's for sure :)
Thanks,
DHB
>
More information about the libvir-list
mailing list