diff for duplicates of <1369758773.18630.1@snotra> diff --git a/a/1.txt b/N1/1.txt index 9f81279..c3c39ca 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,7 +1,7 @@ On 05/24/2013 09:45:24 PM, David Gibson wrote: > On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote: > > On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote: -> > >diff --git a/arch/powerpc/kvm/powerpc.c +> > >diff --git a/arch/powerpc/kvm/powerpc.c =20 > b/arch/powerpc/kvm/powerpc.c > > >index 8465c2a..da6bf61 100644 > > >--- a/arch/powerpc/kvm/powerpc.c @@ -11,34 +11,34 @@ On 05/24/2013 09:45:24 PM, David Gibson wrote: > > > #endif > > > case KVM_CAP_SPAPR_MULTITCE: > > >+ case KVM_CAP_SPAPR_TCE_IOMMU: -> > > r = 1; +> > > r =3D 1; > > > break; > > > default: > > > > Don't advertise SPAPR capabilities if it's not book3s -- and > > probably there's some additional limitation that would be > > appropriate. -> +>=20 > So, in the case of MULTITCE, that's not quite right. PR KVM can > emulate a PAPR system on a BookE machine, and there's no reason not to > allow TCE acceleration as well. -That might (or might not; consider things like Altivec versus SPE -opcode conflict, whether unimplemented SPRs trap, behavior of -unprivileged SPRs/instructions, etc) be true in theory, but it's not -currently a supported configuration. BookE KVM does not support -emulating a different CPU than the host. In the unlikely case that -ever changes to the point of allowing PAPR guests on a BookE host, then -we can revisit how to properly determine whether the capability is -supported, but for now the capability will never be valid in the -CONFIG_BOOKE case (though I'd rather see it depend on an appropriate +That might (or might not; consider things like Altivec versus SPE =20 +opcode conflict, whether unimplemented SPRs trap, behavior of =20 +unprivileged SPRs/instructions, etc) be true in theory, but it's not =20 +currently a supported configuration. BookE KVM does not support =20 +emulating a different CPU than the host. In the unlikely case that =20 +ever changes to the point of allowing PAPR guests on a BookE host, then =20 +we can revisit how to properly determine whether the capability is =20 +supported, but for now the capability will never be valid in the =20 +CONFIG_BOOKE case (though I'd rather see it depend on an appropriate =20 book3s symbol than depend on !BOOKE). -Or we could just leave it as is, and let it indicate whether the host -kernel supports the feature in general, with the user needing to -understand when it's applicable... I'm a bit confused by the -documentation, however -- the MULTITCE capability was documented in the -"capabilities that can be enabled" section, but I don't see where it +Or we could just leave it as is, and let it indicate whether the host =20 +kernel supports the feature in general, with the user needing to =20 +understand when it's applicable... I'm a bit confused by the =20 +documentation, however -- the MULTITCE capability was documented in the =20 +"capabilities that can be enabled" section, but I don't see where it =20 can be enabled. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index ba50a45..540e5c9 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,11 +1,10 @@ "ref\020130525024524.GA6112@boomeroo.fritz.box\0" - "ref\01369105607-20957-4-git-send-email-aik@ozlabs.ru\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling\0" - "Date\0Tue, 28 May 2013 16:32:53 +0000\0" + "Date\0Tue, 28 May 2013 11:32:53 -0500\0" "To\0David Gibson <david@gibson.dropbear.id.au>\0" - "Cc\0Alexey Kardashevskiy <aik@ozlabs.ru>" - kvm@vger.kernel.org + "Cc\0kvm@vger.kernel.org" + Alexey Kardashevskiy <aik@ozlabs.ru> linux-kernel@vger.kernel.org kvm-ppc@vger.kernel.org Alexander Graf <agraf@suse.de> @@ -16,7 +15,7 @@ "On 05/24/2013 09:45:24 PM, David Gibson wrote:\n" "> On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote:\n" "> > On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote:\n" - "> > >diff --git a/arch/powerpc/kvm/powerpc.c \n" + "> > >diff --git a/arch/powerpc/kvm/powerpc.c =20\n" "> b/arch/powerpc/kvm/powerpc.c\n" "> > >index 8465c2a..da6bf61 100644\n" "> > >--- a/arch/powerpc/kvm/powerpc.c\n" @@ -26,36 +25,36 @@ "> > > #endif\n" "> > > \tcase KVM_CAP_SPAPR_MULTITCE:\n" "> > >+\tcase KVM_CAP_SPAPR_TCE_IOMMU:\n" - "> > > \t\tr = 1;\n" + "> > > \t\tr =3D 1;\n" "> > > \t\tbreak;\n" "> > > \tdefault:\n" "> >\n" "> > Don't advertise SPAPR capabilities if it's not book3s -- and\n" "> > probably there's some additional limitation that would be\n" "> > appropriate.\n" - "> \n" + ">=20\n" "> So, in the case of MULTITCE, that's not quite right. PR KVM can\n" "> emulate a PAPR system on a BookE machine, and there's no reason not to\n" "> allow TCE acceleration as well.\n" "\n" - "That might (or might not; consider things like Altivec versus SPE \n" - "opcode conflict, whether unimplemented SPRs trap, behavior of \n" - "unprivileged SPRs/instructions, etc) be true in theory, but it's not \n" - "currently a supported configuration. BookE KVM does not support \n" - "emulating a different CPU than the host. In the unlikely case that \n" - "ever changes to the point of allowing PAPR guests on a BookE host, then \n" - "we can revisit how to properly determine whether the capability is \n" - "supported, but for now the capability will never be valid in the \n" - "CONFIG_BOOKE case (though I'd rather see it depend on an appropriate \n" + "That might (or might not; consider things like Altivec versus SPE =20\n" + "opcode conflict, whether unimplemented SPRs trap, behavior of =20\n" + "unprivileged SPRs/instructions, etc) be true in theory, but it's not =20\n" + "currently a supported configuration. BookE KVM does not support =20\n" + "emulating a different CPU than the host. In the unlikely case that =20\n" + "ever changes to the point of allowing PAPR guests on a BookE host, then =20\n" + "we can revisit how to properly determine whether the capability is =20\n" + "supported, but for now the capability will never be valid in the =20\n" + "CONFIG_BOOKE case (though I'd rather see it depend on an appropriate =20\n" "book3s symbol than depend on !BOOKE).\n" "\n" - "Or we could just leave it as is, and let it indicate whether the host \n" - "kernel supports the feature in general, with the user needing to \n" - "understand when it's applicable... I'm a bit confused by the \n" - "documentation, however -- the MULTITCE capability was documented in the \n" - "\"capabilities that can be enabled\" section, but I don't see where it \n" + "Or we could just leave it as is, and let it indicate whether the host =20\n" + "kernel supports the feature in general, with the user needing to =20\n" + "understand when it's applicable... I'm a bit confused by the =20\n" + "documentation, however -- the MULTITCE capability was documented in the =20\n" + "\"capabilities that can be enabled\" section, but I don't see where it =20\n" "can be enabled.\n" "\n" - -Scott + -Scott= -61c40702c18884d903435a4b53d9520ccb65428b4ce1e411e14a13c7ae0c01f3 +bd32fba47b51fc9a0aaae813b62dad941621a2b2dfcecf117704fac825f0d2a1
diff --git a/a/content_digest b/N2/content_digest index ba50a45..4681a8e 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,16 +1,15 @@ "ref\020130525024524.GA6112@boomeroo.fritz.box\0" - "ref\01369105607-20957-4-git-send-email-aik@ozlabs.ru\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 3/4] KVM: PPC: Add support for IOMMU in-kernel handling\0" - "Date\0Tue, 28 May 2013 16:32:53 +0000\0" + "Date\0Tue, 28 May 2013 11:32:53 -0500\0" "To\0David Gibson <david@gibson.dropbear.id.au>\0" "Cc\0Alexey Kardashevskiy <aik@ozlabs.ru>" - kvm@vger.kernel.org - linux-kernel@vger.kernel.org - kvm-ppc@vger.kernel.org + <kvm@vger.kernel.org> + <linux-kernel@vger.kernel.org> + <kvm-ppc@vger.kernel.org> Alexander Graf <agraf@suse.de> Paul Mackerras <paulus@samba.org> - " linuxppc-dev@lists.ozlabs.org\0" + " <linuxppc-dev@lists.ozlabs.org>\0" "\00:1\0" "b\0" "On 05/24/2013 09:45:24 PM, David Gibson wrote:\n" @@ -58,4 +57,4 @@ "\n" -Scott -61c40702c18884d903435a4b53d9520ccb65428b4ce1e411e14a13c7ae0c01f3 +a63659ea0bcd99144a215d0cbae58c0a8931015b7445519f5c8cd6fbd842bc6f
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.