target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM
commit3f2ca480eb872b4946baf77f756236b637a5b15a
authorDavid Gibson <david@gibson.dropbear.id.au>
Mon, 11 Dec 2017 06:41:34 +0000 (11 17:41 +1100)
committerDavid Gibson <david@gibson.dropbear.id.au>
Tue, 16 Jan 2018 22:35:24 +0000 (17 09:35 +1100)
tree3a3892322cc75f88b167172d2a6341ae68dbbc94
parentbe85537d654565e35e359a74b46fc08b7956525c
target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM

When constructing the "host" cpu class we modify whether the VMX and VSX
vector extensions and DFP (Decimal Floating Point) are available
based on whether KVM can support those instructions.  This can depend on
policy in the host kernel as well as on the actual host cpu capabilities.

However, the way we probe for this is not very nice: we explicitly check
the host's device tree.  That works in practice, but it's not really
correct, since the device tree is a property of the host kernel's platform
which we don't really know about.  We get away with it because the only
modern POWER platforms happen to encode VMX, VSX and DFP availability in
the device tree in the same way.

Arguably we should have an explicit KVM capability for this, but we haven't
needed one so far.  Barring specific KVM policies which don't yet exist,
each of these instruction classes will be available in the guest if and
only if they're available in the qemu userspace process.  We can determine
that from the ELF AUX vector we're supplied with.

Once reworked like this, there are no more callers for kvmppc_get_vmx() and
kvmppc_get_dfp() so remove them.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Greg Kurz <groug@kaod.org>
target/ppc/kvm.c
target/ppc/kvm_ppc.h