diff options
author | David Gibson | 2017-12-11 07:41:34 +0100 |
---|---|---|
committer | David Gibson | 2018-01-16 23:35:24 +0100 |
commit | 3f2ca480eb872b4946baf77f756236b637a5b15a (patch) | |
tree | 3a3892322cc75f88b167172d2a6341ae68dbbc94 /include/hw/ppc/spapr.h | |
parent | spapr: Validate capabilities on migration (diff) | |
download | qemu-3f2ca480eb872b4946baf77f756236b637a5b15a.tar.gz qemu-3f2ca480eb872b4946baf77f756236b637a5b15a.tar.xz qemu-3f2ca480eb872b4946baf77f756236b637a5b15a.zip |
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>
Diffstat (limited to 'include/hw/ppc/spapr.h')
0 files changed, 0 insertions, 0 deletions