qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: peter.maydell@linaro.org
Cc: groug@kaod.org, qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	lvivier@redhat.com, David Gibson <david@gibson.dropbear.id.au>
Subject: [Qemu-devel] [PULL 10/15] target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM
Date: Wed,  3 Jan 2018 15:24:14 +1100	[thread overview]
Message-ID: <20180103042419.14520-11-david@gibson.dropbear.id.au> (raw)
In-Reply-To: <20180103042419.14520-1-david@gibson.dropbear.id.au>

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     | 27 ++++++---------------------
 target/ppc/kvm_ppc.h |  2 --
 2 files changed, 6 insertions(+), 23 deletions(-)

diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
index 4664a3ce9d..518dd06e98 100644
--- a/target/ppc/kvm.c
+++ b/target/ppc/kvm.c
@@ -2011,16 +2011,6 @@ uint64_t kvmppc_get_clockfreq(void)
     return kvmppc_read_int_cpu_dt("clock-frequency");
 }
 
-uint32_t kvmppc_get_vmx(void)
-{
-    return kvmppc_read_int_cpu_dt("ibm,vmx");
-}
-
-uint32_t kvmppc_get_dfp(void)
-{
-    return kvmppc_read_int_cpu_dt("ibm,dfp");
-}
-
 static int kvmppc_get_pvinfo(CPUPPCState *env, struct kvm_ppc_pvinfo *pvinfo)
  {
      PowerPCCPU *cpu = ppc_env_get_cpu(env);
@@ -2404,23 +2394,18 @@ static void alter_insns(uint64_t *word, uint64_t flags, bool on)
 static void kvmppc_host_cpu_class_init(ObjectClass *oc, void *data)
 {
     PowerPCCPUClass *pcc = POWERPC_CPU_CLASS(oc);
-    uint32_t vmx = kvmppc_get_vmx();
-    uint32_t dfp = kvmppc_get_dfp();
     uint32_t dcache_size = kvmppc_read_int_cpu_dt("d-cache-size");
     uint32_t icache_size = kvmppc_read_int_cpu_dt("i-cache-size");
 
     /* Now fix up the class with information we can query from the host */
     pcc->pvr = mfpvr();
 
-    if (vmx != -1) {
-        /* Only override when we know what the host supports */
-        alter_insns(&pcc->insns_flags, PPC_ALTIVEC, vmx > 0);
-        alter_insns(&pcc->insns_flags2, PPC2_VSX, vmx > 1);
-    }
-    if (dfp != -1) {
-        /* Only override when we know what the host supports */
-        alter_insns(&pcc->insns_flags2, PPC2_DFP, dfp);
-    }
+    alter_insns(&pcc->insns_flags, PPC_ALTIVEC,
+                qemu_getauxval(AT_HWCAP) & PPC_FEATURE_HAS_ALTIVEC);
+    alter_insns(&pcc->insns_flags2, PPC2_VSX,
+                qemu_getauxval(AT_HWCAP) & PPC_FEATURE_HAS_VSX);
+    alter_insns(&pcc->insns_flags2, PPC2_DFP,
+                qemu_getauxval(AT_HWCAP) & PPC_FEATURE_HAS_DFP);
 
     if (dcache_size != -1) {
         pcc->l1_dcache_size = dcache_size;
diff --git a/target/ppc/kvm_ppc.h b/target/ppc/kvm_ppc.h
index d6be38ecaf..ecb55493cc 100644
--- a/target/ppc/kvm_ppc.h
+++ b/target/ppc/kvm_ppc.h
@@ -15,8 +15,6 @@
 
 uint32_t kvmppc_get_tbfreq(void);
 uint64_t kvmppc_get_clockfreq(void);
-uint32_t kvmppc_get_vmx(void);
-uint32_t kvmppc_get_dfp(void);
 bool kvmppc_get_host_model(char **buf);
 bool kvmppc_get_host_serial(char **buf);
 int kvmppc_get_hasidle(CPUPPCState *env);
-- 
2.14.3

  parent reply	other threads:[~2018-01-03  4:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-03  4:24 [Qemu-devel] [PULL 00/15] ppc-for-2.12 queue 20180103 David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 01/15] target-ppc: optimize cmp translation David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 02/15] pseries: Update SLOF firmware image to qemu-slof-20171214 David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 03/15] sm501: Add panel hardware cursor registers also to read function David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 04/15] sm501: Add some more unimplemented registers David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 05/15] ppc4xx_i2c: Implement basic I2C functions David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 06/15] ppc/pnv: change powernv_ prefix to pnv_ for overall naming consistency David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 07/15] spapr: Capabilities infrastructure David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 08/15] spapr: Treat Hardware Transactional Memory (HTM) as an optional capability David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 09/15] spapr: Validate capabilities on migration David Gibson
2018-01-03  4:24 ` David Gibson [this message]
2018-01-03  4:24 ` [Qemu-devel] [PULL 11/15] spapr: Handle VMX/VSX presence as an spapr capability flag David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 12/15] spapr: Handle Decimal Floating Point (DFP) as an optional capability David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 13/15] spapr_pci: use warn_report() David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 14/15] hw/ide: Emulate SiI3112 SATA controller David Gibson
2018-01-03  4:24 ` [Qemu-devel] [PULL 15/15] target/ppc: more use of the PPC_*() macros David Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180103042419.14520-11-david@gibson.dropbear.id.au \
    --to=david@gibson.dropbear.id.au \
    --cc=groug@kaod.org \
    --cc=lvivier@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).