diff for duplicates of <1369763138.18630.3@snotra> diff --git a/a/1.txt b/N1/1.txt index 91df7e6..0538d1c 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -2,7 +2,7 @@ On 05/26/2013 09:44:24 PM, Alexey Kardashevskiy wrote: > On 05/25/2013 12:45 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 @@ -12,7 +12,7 @@ On 05/26/2013 09:44:24 PM, Alexey Kardashevskiy wrote: > >>> #endif > >>> case KVM_CAP_SPAPR_MULTITCE: > >>> + case KVM_CAP_SPAPR_TCE_IOMMU: -> >>> r = 1; +> >>> r =3D 1; > >>> break; > >>> default: > >> @@ -21,7 +21,7 @@ On 05/26/2013 09:44:24 PM, Alexey Kardashevskiy wrote: > >> appropriate. > > > > 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 +> > emulate a PAPR system on a BookE machine, and there's no reason not =20 > to > > allow TCE acceleration as well. We can't make it dependent on PAPR > > mode being selected, because that's enabled per-vcpu, whereas these @@ -29,18 +29,18 @@ On 05/26/2013 09:44:24 PM, Alexey Kardashevskiy wrote: > > > > CAP_SPAPR_TCE_IOMMU should be dependent on the presence of suitable > > host side hardware (i.e. a PAPR style IOMMU), though. -> -> -> The capability says that the ioctl is supported. If there is no IOMMU +>=20 +>=20 +> The capability says that the ioctl is supported. If there is no IOMMU =20 > group -> registered, than it will fail with a reasonable error and nobody gets +> registered, than it will fail with a reasonable error and nobody gets =20 > hurt. > What is the problem? -You could say that about a lot of the capabilities that just advertise +You could say that about a lot of the capabilities that just advertise =20 the existence of new ioctls. :-) -Sometimes it's nice to know in advance whether it's supported, before +Sometimes it's nice to know in advance whether it's supported, before =20 actually requesting that something happen. > >>> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping { @@ -54,13 +54,13 @@ actually requesting that something happen. > >>> kvm_create_spapr_tce_iommu) > >> > >> Shouldn't this go under the vm ioctl section? -> -> -> The KVM_CREATE_SPAPR_TCE_IOMMU ioctl (the version for emulated +>=20 +>=20 +> The KVM_CREATE_SPAPR_TCE_IOMMU ioctl (the version for emulated =20 > devices) is > in this section so I decided to keep them together. Wrong? -You decided to keep KVM_CREATE_SPAPR_TCE_IOMMU together with +You decided to keep KVM_CREATE_SPAPR_TCE_IOMMU together with =20 KVM_CREATE_SPAPR_TCE_IOMMU? --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index 80f031f..5362ddb 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,23 +1,22 @@ "ref\051A2C888.4050704@ozlabs.ru\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 17:45:38 +0000\0" + "Date\0Tue, 28 May 2013 12:45:38 -0500\0" "To\0Alexey Kardashevskiy <aik@ozlabs.ru>\0" - "Cc\0David Gibson <david@gibson.dropbear.id.au>" - kvm@vger.kernel.org - linux-kernel@vger.kernel.org - kvm-ppc@vger.kernel.org + "Cc\0kvm@vger.kernel.org" Alexander Graf <agraf@suse.de> + kvm-ppc@vger.kernel.org + linux-kernel@vger.kernel.org Paul Mackerras <paulus@samba.org> - " linuxppc-dev@lists.ozlabs.org\0" + linuxppc-dev@lists.ozlabs.org + " David Gibson <david@gibson.dropbear.id.au>\0" "\00:1\0" "b\0" "On 05/26/2013 09:44:24 PM, Alexey Kardashevskiy wrote:\n" "> On 05/25/2013 12:45 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" @@ -27,7 +26,7 @@ "> >>> #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" @@ -36,7 +35,7 @@ "> >> appropriate.\n" "> >\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 \n" + "> > emulate a PAPR system on a BookE machine, and there's no reason not =20\n" "> to\n" "> > allow TCE acceleration as well. We can't make it dependent on PAPR\n" "> > mode being selected, because that's enabled per-vcpu, whereas these\n" @@ -44,18 +43,18 @@ "> >\n" "> > CAP_SPAPR_TCE_IOMMU should be dependent on the presence of suitable\n" "> > host side hardware (i.e. a PAPR style IOMMU), though.\n" - "> \n" - "> \n" - "> The capability says that the ioctl is supported. If there is no IOMMU \n" + ">=20\n" + ">=20\n" + "> The capability says that the ioctl is supported. If there is no IOMMU =20\n" "> group\n" - "> registered, than it will fail with a reasonable error and nobody gets \n" + "> registered, than it will fail with a reasonable error and nobody gets =20\n" "> hurt.\n" "> What is the problem?\n" "\n" - "You could say that about a lot of the capabilities that just advertise \n" + "You could say that about a lot of the capabilities that just advertise =20\n" "the existence of new ioctls. :-)\n" "\n" - "Sometimes it's nice to know in advance whether it's supported, before \n" + "Sometimes it's nice to know in advance whether it's supported, before =20\n" "actually requesting that something happen.\n" "\n" "> >>> @@ -939,6 +940,9 @@ struct kvm_s390_ucas_mapping {\n" @@ -69,15 +68,15 @@ "> >>> kvm_create_spapr_tce_iommu)\n" "> >>\n" "> >> Shouldn't this go under the vm ioctl section?\n" - "> \n" - "> \n" - "> The KVM_CREATE_SPAPR_TCE_IOMMU ioctl (the version for emulated \n" + ">=20\n" + ">=20\n" + "> The KVM_CREATE_SPAPR_TCE_IOMMU ioctl (the version for emulated =20\n" "> devices) is\n" "> in this section so I decided to keep them together. Wrong?\n" "\n" - "You decided to keep KVM_CREATE_SPAPR_TCE_IOMMU together with \n" + "You decided to keep KVM_CREATE_SPAPR_TCE_IOMMU together with =20\n" "KVM_CREATE_SPAPR_TCE_IOMMU?\n" "\n" - -Scott + -Scott= -15fc5ba9e19b24d1b3edcf11793f905d4a8aa9406691511123a3d21ca5e2fce6 +b44f69d26ced7722d8e3913df5c714dfc112806b18e2b77d4714d4159842ea6e
diff --git a/a/content_digest b/N2/content_digest index 80f031f..e4fa013 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,16 +1,15 @@ "ref\051A2C888.4050704@ozlabs.ru\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 17:45:38 +0000\0" + "Date\0Tue, 28 May 2013 12:45:38 -0500\0" "To\0Alexey Kardashevskiy <aik@ozlabs.ru>\0" "Cc\0David Gibson <david@gibson.dropbear.id.au>" - 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/26/2013 09:44:24 PM, Alexey Kardashevskiy wrote:\n" @@ -80,4 +79,4 @@ "\n" -Scott -15fc5ba9e19b24d1b3edcf11793f905d4a8aa9406691511123a3d21ca5e2fce6 +1e3388840439496f310c5e38da86db0e3efea3a4436195b88d11606c72de6529
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.