ppc/kvm: check some capabilities with kvm_vm_check_extension()
commit6977afda16c1e09dfbce4bdd877459a287269b72
authorGreg Kurz <groug@kaod.org>
Thu, 14 Sep 2017 19:25:43 +0000 (14 21:25 +0200)
committerDavid Gibson <david@gibson.dropbear.id.au>
Wed, 27 Sep 2017 03:05:41 +0000 (27 13:05 +1000)
treec96e76a56085df984070be581a58a2a135c824a9
parent31bc1d8481af414cfa2857f905e40f7d8e6d5b2e
ppc/kvm: check some capabilities with kvm_vm_check_extension()

The following capabilities are VM specific:
- KVM_CAP_PPC_SMT_POSSIBLE
- KVM_CAP_PPC_HTAB_FD
- KVM_CAP_PPC_ALLOC_HTAB

If both KVM HV and KVM PR are present, checking them always return
the HV value, even if we explicitely requested to use PR.

This has no visible effect for KVM_CAP_PPC_ALLOC_HTAB, because we also
try the KVM_PPC_ALLOCATE_HTAB ioctl which is only suppored by HV. As
a consequence, the spapr code doesn't even check KVM_CAP_PPC_HTAB_FD.

However, this will cause kvmppc_hint_smt_possible(), introduced by
commit fa98fbfcdfcb9, to report several VSMT modes (eg, Available
VSMT modes: 8 4 2 1) whereas PR only support mode 1.

This patch fixes all three anyway to use kvm_vm_check_extension(). It
is okay since the VM is already created at the time kvm_arch_init() or
kvmppc_reset_htab() is called.

Signed-off-by: Greg Kurz <groug@kaod.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
target/ppc/kvm.c