qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: surajjs@au1.ibm.com, lvivier@redhat.com, qemu-ppc@nongnu.org,
	qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com,
	abologna@redhat.com
Subject: Re: [Qemu-devel] [PATCH 4/6] target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM
Date: Mon, 18 Dec 2017 12:45:40 +0100	[thread overview]
Message-ID: <20171218124540.7da45454@bahia.lan> (raw)
In-Reply-To: <20171218092024.21645-5-david@gibson.dropbear.id.au>

On Mon, 18 Dec 2017 20:20:22 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> 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 9d57debf0e..81d9bd56c7 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -2014,16 +2014,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);
> @@ -2407,23 +2397,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);

  reply	other threads:[~2017-12-18 11:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-18  9:20 [Qemu-devel] [PATCH 0/6] spapr: Add optional capabilities David Gibson
2017-12-18  9:20 ` [Qemu-devel] [PATCH 1/6] spapr: Capabilities infrastructure David Gibson
2017-12-18  9:58   ` Greg Kurz
2017-12-18 10:15     ` David Gibson
2017-12-18  9:20 ` [Qemu-devel] [PATCH 2/6] spapr: Treat Hardware Transactional Memory (HTM) as an optional capability David Gibson
2017-12-18 11:10   ` Greg Kurz
2017-12-19  0:35     ` David Gibson
2017-12-18  9:20 ` [Qemu-devel] [PATCH 3/6] spapr: Validate capabilities on migration David Gibson
2017-12-18 11:31   ` Greg Kurz
2017-12-18  9:20 ` [Qemu-devel] [PATCH 4/6] target/ppc: Clean up probing of VMX, VSX and DFP availability on KVM David Gibson
2017-12-18 11:45   ` Greg Kurz [this message]
2017-12-18  9:20 ` [Qemu-devel] [PATCH 5/6] spapr: Handle VMX/VSX presence as an spapr capability flag David Gibson
2017-12-18 11:47   ` Greg Kurz
2017-12-18  9:20 ` [Qemu-devel] [PATCH 6/6] spapr: Handle Decimal Floating Point (DFP) as an optional capability David Gibson
2017-12-18 11:51   ` Greg Kurz
2017-12-19  0:37 ` [Qemu-devel] [PATCH 0/6] spapr: Add optional capabilities David Gibson
2017-12-20 22:32 ` Benjamin Herrenschmidt

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=20171218124540.7da45454@bahia.lan \
    --to=groug@kaod.org \
    --cc=abologna@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=lvivier@redhat.com \
    --cc=mdroth@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=surajjs@au1.ibm.com \
    /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).