From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afXxO-00089O-6T for qemu-devel@nongnu.org; Mon, 14 Mar 2016 15:15:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afXxJ-0003Tm-U8 for qemu-devel@nongnu.org; Mon, 14 Mar 2016 15:15:10 -0400 References: <1457974600-13828-1-git-send-email-clg@fr.ibm.com> <1457974600-13828-4-git-send-email-clg@fr.ibm.com> From: Thomas Huth Message-ID: <56E70DB3.8080802@redhat.com> Date: Mon, 14 Mar 2016 20:14:59 +0100 MIME-Version: 1.0 In-Reply-To: <1457974600-13828-4-git-send-email-clg@fr.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 03/17] ppc: Add a bunch of hypervisor SPRs to Book3s List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= , David Gibson Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org On 14.03.2016 17:56, C=C3=A9dric Le Goater wrote: > From: Benjamin Herrenschmidt >=20 > We don't give them a KVM reg number to most of the registers yet as no > current KVM version supports HV mode. For DAWR and DAWRX, the KVM reg > number is needed since this register can be set by the guest via the > H_SET_MODE hypercall. >=20 > Signed-off-by: Benjamin Herrenschmidt > [clg: squashed in patch 'ppc: Add KVM numbers to some P8 SPRs' and > changed the commit log with a proposal of Thomas Huth ] > Signed-off-by: C=C3=A9dric Le Goater > --- > target-ppc/translate_init.c | 140 ++++++++++++++++++++++++++++++++++++= +++++++- > 1 file changed, 137 insertions(+), 3 deletions(-) >=20 > diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c > index 6a11b41206e5..43c6e524a6bc 100644 > --- a/target-ppc/translate_init.c > +++ b/target-ppc/translate_init.c > @@ -1105,6 +1105,11 @@ static void gen_spr_amr (CPUPPCState *env) > SPR_NOACCESS, SPR_NOACCESS, > &spr_read_generic, &spr_write_generic, > KVM_REG_PPC_UAMOR, 0); > + spr_register_hv(env, SPR_AMOR, "AMOR", > + SPR_NOACCESS, SPR_NOACCESS, > + SPR_NOACCESS, SPR_NOACCESS, > + &spr_read_generic, &spr_write_generic, > + 0); > #endif /* !CONFIG_USER_ONLY */ > } > #endif /* TARGET_PPC64 */ > @@ -7491,6 +7496,20 @@ static void gen_spr_book3s_dbg(CPUPPCState *env) > KVM_REG_PPC_DABRX, 0x00000000); > } > =20 > +static void gen_spr_book3s_207_dbg(CPUPPCState *env) > +{ > + spr_register_kvm_hv(env, SPR_DAWR, "DAWR", > + SPR_NOACCESS, SPR_NOACCESS, > + SPR_NOACCESS, SPR_NOACCESS, > + &spr_read_generic, &spr_write_generic, > + KVM_REG_PPC_DAWR, 0x00000000); > + spr_register_kvm_hv(env, SPR_DAWRX, "DAWRX", > + SPR_NOACCESS, SPR_NOACCESS, > + SPR_NOACCESS, SPR_NOACCESS, > + &spr_read_generic, &spr_write_generic, > + KVM_REG_PPC_DAWRX, 0x00000000); > +} > + > static void gen_spr_970_dbg(CPUPPCState *env) > { > /* Breakpoints */ > @@ -7683,15 +7702,116 @@ static void gen_spr_power5p_lpar(CPUPPCState *= env) > spr_register_kvm(env, SPR_LPCR, "LPCR", > SPR_NOACCESS, SPR_NOACCESS, > &spr_read_generic, &spr_write_generic, > - KVM_REG_PPC_LPCR, 0x00000000); > + KVM_REG_PPC_LPCR, LPCR_LPES0 | LPCR_LPES1); Could we please postpone that hunk to a later, separate patch (after QEMU 2.6 has been released)? It looks like it could maybe cause some trouble with some emulated boards (e.g. there is some code in target-ppc/excp_helper.c for example - which is currently disabled, but I'm not sure whether there are other spots like this somewhere else). > } > =20 > +#if !defined(CONFIG_USER_ONLY) > +static void spr_write_hmer(DisasContext *ctx, int sprn, int gprn) > +{ > + TCGv hmer =3D tcg_temp_new(); > + > + gen_load_spr(hmer, sprn); > + tcg_gen_and_tl(hmer, cpu_gpr[gprn], hmer); > + gen_store_spr(sprn, hmer); > + spr_store_dump_spr(sprn); > + tcg_temp_free(hmer); > +} > +#endif > + > static void gen_spr_book3s_ids(CPUPPCState *env) > { > + /* FIXME: Will need to deal with thread vs core only SPRs */ > + > /* Processor identification */ > - spr_register(env, SPR_PIR, "PIR", > + spr_register_hv(env, SPR_PIR, "PIR", > SPR_NOACCESS, SPR_NOACCESS, > - &spr_read_generic, &spr_write_pir, > + SPR_NOACCESS, SPR_NOACCESS, > + &spr_read_generic, NULL, > + 0x00000000); What does the NULL mean here? I haven't seen any other spr_register*() calls yet that pass NULL as parameter for a handler. Should that maybe rather be a SPR_NOACCESS instead? Thomas