diff for duplicates of <1372877073.8183.140@snotra> diff --git a/a/1.txt b/N1/1.txt index 22222cd..bbaccbb 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,35 +1,35 @@ On 07/03/2013 01:42:12 PM, Alexander Graf wrote: -> +>=20 > On 03.07.2013, at 20:28, Scott Wood wrote: -> +>=20 > > On 07/03/2013 10:13:57 AM, Alexander Graf wrote: -> >> 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 +> >> There is no chip that supports SPE and HV at the same time. So =20 +> we'll never hit this anyway, since kvmppc_supports_spe() always =20 > returns false on HV capable systems. > >> 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 think we still need the ifdef +> > 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 =20 +> on the "if (kvmppc_supports_spe())" here because a later patch =20 +> changes it to "if (kvmppc_supports_altivec() || =20 +> kvmppc_supports_spe())". So I think we still need the ifdef =20 > 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. -> -> So we should make this an #ifdef CONFIG_SPE rather than #ifndef +>=20 +> So we should make this an #ifdef CONFIG_SPE rather than #ifndef =20 > CONFIG_KVM_BOOKE_HV? -I think it should be "#if !defined(CONFIG_KVM_BOOKE_HV) && +I think it should be "#if !defined(CONFIG_KVM_BOOKE_HV) && =20 defined(CONFIG_SPE)" for the reasons I described in my second paragraph. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index 3a043d4..560fbee 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,48 +2,48 @@ "ref\05BA99D8C-1B46-472C-97F7-4A174A39A6D7@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:44:33 +0000\0" + "Date\0Wed, 3 Jul 2013 13:44:33 -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 01:42:12 PM, Alexander Graf wrote:\n" - "> \n" + ">=20\n" "> On 03.07.2013, at 20:28, Scott Wood wrote:\n" - "> \n" + ">=20\n" "> > On 07/03/2013 10:13:57 AM, Alexander Graf wrote:\n" - "> >> There is no chip that supports SPE and HV at the same time. So \n" - "> we'll never hit this anyway, since kvmppc_supports_spe() always \n" + "> >> There is no chip that supports SPE and HV at the same time. So =20\n" + "> we'll never hit this anyway, since kvmppc_supports_spe() always =20\n" "> returns false on HV capable systems.\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 \n" - "> on the \"if (kvmppc_supports_spe())\" here because a later patch \n" - "> changes it to \"if (kvmppc_supports_altivec() || \n" - "> kvmppc_supports_spe())\". So I think we still need the ifdef \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 =20\n" + "> on the \"if (kvmppc_supports_spe())\" here because a later patch =20\n" + "> changes it to \"if (kvmppc_supports_altivec() || =20\n" + "> kvmppc_supports_spe())\". So I think we still need the ifdef =20\n" "> 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" - "> So we should make this an #ifdef CONFIG_SPE rather than #ifndef \n" + ">=20\n" + "> So we should make this an #ifdef CONFIG_SPE rather than #ifndef =20\n" "> CONFIG_KVM_BOOKE_HV?\n" "\n" - "I think it should be \"#if !defined(CONFIG_KVM_BOOKE_HV) && \n" + "I think it should be \"#if !defined(CONFIG_KVM_BOOKE_HV) && =20\n" "defined(CONFIG_SPE)\" for the reasons I described in my second paragraph.\n" "\n" - -Scott + -Scott= -18c6e19dc0f92d8de50cc70f8501dc4f4903d5c50edc7b495d043bc70329c4fc +228efd9635cfca74c1e6078dd2e78e7b2e272c9200127ae3a7dbc3d4b42fd90a
diff --git a/a/content_digest b/N2/content_digest index 3a043d4..60eda42 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -2,7 +2,7 @@ "ref\05BA99D8C-1B46-472C-97F7-4A174A39A6D7@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:44:33 +0000\0" + "Date\0Wed, 3 Jul 2013 13:44:33 -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> @@ -46,4 +46,4 @@ "\n" -Scott -18c6e19dc0f92d8de50cc70f8501dc4f4903d5c50edc7b495d043bc70329c4fc +f17b558b7f7a2471e305e70147ba3effce65fc29651c9427b63bdf2f9d4bdd3d
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.