diff for duplicates of <1372876139.8183.135@snotra> diff --git a/a/1.txt b/N1/1.txt index 4c74c33..47a38ad 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,7 +1,7 @@ On 07/03/2013 10:13:57 AM, Alexander Graf wrote: -> +>=20 > On 03.07.2013, at 15:53, Caraman Mihai Claudiu-B02008 wrote: -> +>=20 > >>> -#ifdef CONFIG_SPE > >>> case BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL: { > >>> - if (vcpu->arch.shared->msr & MSR_SPE) @@ -11,45 +11,45 @@ > >>> - > >> BOOKE_IRQPRIO_SPE_ALTIVEC_UNAVAIL); > >>> + if (kvmppc_supports_spe()) { -> >>> + bool enabled = false; +> >>> + bool enabled =3D false; > >>> + > >>> +#ifndef CONFIG_KVM_BOOKE_HV > >>> + if (vcpu->arch.shared->msr & MSR_SPE) { > >>> + kvmppc_vcpu_enable_spe(vcpu); -> >>> + enabled = true; +> >>> + enabled =3D true; > >>> + } > >>> +#endif > >> -> >> Why the #ifdef? On HV capable systems kvmppc_supports_spe() will +> >> Why the #ifdef? On HV capable systems kvmppc_supports_spe() will =20 > just > >> always return false. > > > > AltiVec and SPE unavailable exceptions follows the same path. While -> > kvmppc_supports_spe() will always return false +> > kvmppc_supports_spe() will always return false =20 > kvmppc_supports_altivec() > > may not. -> -> There is no chip that supports SPE and HV at the same time. So we'll -> never hit this anyway, since kvmppc_supports_spe() always returns +>=20 +> There is no chip that supports SPE and HV at the same time. So we'll =20 +> never hit this anyway, since kvmppc_supports_spe() always returns =20 > false on HV capable systems. -> +>=20 > Just add a comment saying so and remove the ifdef :). -kvmppc_vcpu_enable_spe isn't defined unless CONFIG_SPE is defined. -More seriously, MSR_SPE is the same as MSR_VEC, so we shouldn't -interpret it as SPE unless CONFIG_SPE is defined. And we can't rely on -the "if (kvmppc_supports_spe())" here because a later patch changes it -to "if (kvmppc_supports_altivec() || kvmppc_supports_spe())". So I +kvmppc_vcpu_enable_spe isn't defined unless CONFIG_SPE is defined. =20 +More seriously, MSR_SPE is the same as MSR_VEC, so we shouldn't =20 +interpret it as SPE unless CONFIG_SPE is defined. And we can't rely on =20 +the "if (kvmppc_supports_spe())" here because a later patch changes it =20 +to "if (kvmppc_supports_altivec() || kvmppc_supports_spe())". So I =20 think we still need the ifdef CONFIG_SPE here. -As for the HV ifndef, we should try not to confuse HV/PR with -e500mc/e500v2, even if we happen to only run HV on e500mc and PR on -e500v2. We would not want to call kvmppc_vcpu_enable_spe() here on a -hypothetical HV target with SPE. And we *would* want to call -kvmppc_vcpu_enable_fp() here on a hypothetical PR target with normal -FP. It's one thing to leave out the latter, since it would involve -writing actual code that we have no way to test at this point, but -quite another to leave out the proper conditions for when we want to +As for the HV ifndef, we should try not to confuse HV/PR with =20 +e500mc/e500v2, even if we happen to only run HV on e500mc and PR on =20 +e500v2. We would not want to call kvmppc_vcpu_enable_spe() here on a =20 +hypothetical HV target with SPE. And we *would* want to call =20 +kvmppc_vcpu_enable_fp() here on a hypothetical PR target with normal =20 +FP. It's one thing to leave out the latter, since it would involve =20 +writing actual code that we have no way to test at this point, but =20 +quite another to leave out the proper conditions for when we want to =20 run code that we do have. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index c0e621d..363b726 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,18 +1,18 @@ "ref\04C6EF5E2-013B-4EA7-8DDC-586BF8FBE741@suse.de\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 2/6] KVM: PPC: Book3E: Refactor SPE/FP exit handling\0" - "Date\0Wed, 03 Jul 2013 18:28:59 +0000\0" + "Date\0Wed, 3 Jul 2013 13:28:59 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>" - kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org> + linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org> kvm@vger.kernel.org <kvm@vger.kernel.org> - " linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>\0" + " kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org>\0" "\00:1\0" "b\0" " On 07/03/2013 10:13:57 AM, Alexander Graf wrote:\n" - "> \n" + ">=20\n" "> On 03.07.2013, at 15:53, Caraman Mihai Claudiu-B02008 wrote:\n" - "> \n" + ">=20\n" "> >>> -#ifdef CONFIG_SPE\n" "> >>> \tcase BOOKE_INTERRUPT_SPE_ALTIVEC_UNAVAIL: {\n" "> >>> -\t\tif (vcpu->arch.shared->msr & MSR_SPE)\n" @@ -22,47 +22,47 @@ "> >>> -\n" "> >> BOOKE_IRQPRIO_SPE_ALTIVEC_UNAVAIL);\n" "> >>> +\t\tif (kvmppc_supports_spe()) {\n" - "> >>> +\t\t\tbool enabled = false;\n" + "> >>> +\t\t\tbool enabled =3D false;\n" "> >>> +\n" "> >>> +#ifndef CONFIG_KVM_BOOKE_HV\n" "> >>> +\t\t\tif (vcpu->arch.shared->msr & MSR_SPE) {\n" "> >>> +\t\t\t\tkvmppc_vcpu_enable_spe(vcpu);\n" - "> >>> +\t\t\t\tenabled = true;\n" + "> >>> +\t\t\t\tenabled =3D true;\n" "> >>> +\t\t\t}\n" "> >>> +#endif\n" "> >>\n" - "> >> Why the #ifdef? On HV capable systems kvmppc_supports_spe() will \n" + "> >> Why the #ifdef? On HV capable systems kvmppc_supports_spe() will =20\n" "> just\n" "> >> always return false.\n" "> >\n" "> > AltiVec and SPE unavailable exceptions follows the same path. While\n" - "> > kvmppc_supports_spe() will always return false \n" + "> > kvmppc_supports_spe() will always return false =20\n" "> kvmppc_supports_altivec()\n" "> > may not.\n" - "> \n" - "> There is no chip that supports SPE and HV at the same time. So we'll \n" - "> never hit this anyway, since kvmppc_supports_spe() always returns \n" + ">=20\n" + "> There is no chip that supports SPE and HV at the same time. So we'll =20\n" + "> never hit this anyway, since kvmppc_supports_spe() always returns =20\n" "> false on HV capable systems.\n" - "> \n" + ">=20\n" "> Just add a comment saying so and remove the ifdef :).\n" "\n" - "kvmppc_vcpu_enable_spe isn't defined unless CONFIG_SPE is defined. \n" - "More seriously, MSR_SPE is the same as MSR_VEC, so we shouldn't \n" - "interpret it as SPE unless CONFIG_SPE is defined. And we can't rely on \n" - "the \"if (kvmppc_supports_spe())\" here because a later patch changes it \n" - "to \"if (kvmppc_supports_altivec() || kvmppc_supports_spe())\". So I \n" + "kvmppc_vcpu_enable_spe isn't defined unless CONFIG_SPE is defined. =20\n" + "More seriously, MSR_SPE is the same as MSR_VEC, so we shouldn't =20\n" + "interpret it as SPE unless CONFIG_SPE is defined. And we can't rely on =20\n" + "the \"if (kvmppc_supports_spe())\" here because a later patch changes it =20\n" + "to \"if (kvmppc_supports_altivec() || kvmppc_supports_spe())\". So I =20\n" "think we still need the ifdef CONFIG_SPE here.\n" "\n" - "As for the HV ifndef, we should try not to confuse HV/PR with \n" - "e500mc/e500v2, even if we happen to only run HV on e500mc and PR on \n" - "e500v2. We would not want to call kvmppc_vcpu_enable_spe() here on a \n" - "hypothetical HV target with SPE. And we *would* want to call \n" - "kvmppc_vcpu_enable_fp() here on a hypothetical PR target with normal \n" - "FP. It's one thing to leave out the latter, since it would involve \n" - "writing actual code that we have no way to test at this point, but \n" - "quite another to leave out the proper conditions for when we want to \n" + "As for the HV ifndef, we should try not to confuse HV/PR with =20\n" + "e500mc/e500v2, even if we happen to only run HV on e500mc and PR on =20\n" + "e500v2. We would not want to call kvmppc_vcpu_enable_spe() here on a =20\n" + "hypothetical HV target with SPE. And we *would* want to call =20\n" + "kvmppc_vcpu_enable_fp() here on a hypothetical PR target with normal =20\n" + "FP. It's one thing to leave out the latter, since it would involve =20\n" + "writing actual code that we have no way to test at this point, but =20\n" + "quite another to leave out the proper conditions for when we want to =20\n" "run code that we do have.\n" "\n" - -Scott + -Scott= -96c323b3d43585a7d3e78099346d2f98bd2c185f5b26609e5333e0f2c43eec38 +66f60a388868b290696036d750e2c5251d04268c84aa0ce9e955fb0450070db7
diff --git a/a/content_digest b/N2/content_digest index c0e621d..e2bb650 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,7 +1,7 @@ "ref\04C6EF5E2-013B-4EA7-8DDC-586BF8FBE741@suse.de\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 2/6] KVM: PPC: Book3E: Refactor SPE/FP exit handling\0" - "Date\0Wed, 03 Jul 2013 18:28:59 +0000\0" + "Date\0Wed, 3 Jul 2013 13:28:59 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>" kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org> @@ -65,4 +65,4 @@ "\n" -Scott -96c323b3d43585a7d3e78099346d2f98bd2c185f5b26609e5333e0f2c43eec38 +d5a6958445bec1124bb09777243e1df3d53005b32f96ecd188d6e29b88b0049a
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.