diff for duplicates of <1359650904.31540.0@snotra> diff --git a/a/1.txt b/N1/1.txt index 243e27a..72f0bc9 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -17,7 +17,7 @@ On 01/31/2013 09:26:20 AM, Caraman Mihai Claudiu-B02008 wrote: > > >> To: Caraman Mihai Claudiu-B02008 > > >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc- > > >> dev@lists.ozlabs.org -> > >> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG +> > >> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG =20 > register > > >> initialization earlier > > >> @@ -28,9 +28,9 @@ On 01/31/2013 09:26:20 AM, Caraman Mihai Claudiu-B02008 wrote: > > >> KVM_CAP_SW_TLB > > >>> ioctl call. Move it earlier into tlb initalization phase. > > >> -> > >> Quite the contrary. The fact that there is an mfspr() in +> > >> Quite the contrary. The fact that there is an mfspr() in =20 > e500_mmu.c -> > >> already tells us that the code is broken. The TLB guest code +> > >> already tells us that the code is broken. The TLB guest code =20 > should > > only > > >> depend on input from the SW_TLB configuration. It's completely @@ -39,38 +39,38 @@ On 01/31/2013 09:26:20 AM, Caraman Mihai Claudiu-B02008 wrote: > > > > > > Then we have the same issue for TLBnCFG registers which need to be > > configured -> > > via SW_TLB ioctl. What is the purpose of guest tlb initalization +> > > via SW_TLB ioctl. What is the purpose of guest tlb initalization =20 > in > > e500_mmu.c > > > if we rely on SW_TLB? > > -> > It's to provide a fallback to user space that doesn't implement +> > It's to provide a fallback to user space that doesn't implement =20 > SW_TLB > > configuration yet. -> -> Do we have such a case now or is it just hypothetical? For the +>=20 +> Do we have such a case now or is it just hypothetical? For the =20 > fallback we -> need to initialize the MMUCFG register which I intended to say in the +> need to initialize the MMUCFG register which I intended to say in the =20 > commit > message. -I don't think we need to support a fallback for e6500, since there's +I don't think we need to support a fallback for e6500, since there's =20 nothing to be backwards compatible with. -As for use case, I don't see us ever supporting the guest being a -different CPU than the host. Page sizes probably aren't a problem, but +As for use case, I don't see us ever supporting the guest being a =20 +different CPU than the host. Page sizes probably aren't a problem, but =20 there are other barriers. The main reasons that TLBnCFG are settable through SW_TLB are: -1. The guest TLB can be enlarged as a performance hack (like in Topaz, +1. The guest TLB can be enlarged as a performance hack (like in Topaz, =20 though QEMU doesn't currently do this), -2. The legacy default in KVM is based on the e500v1 TLB0 size, which is +2. The legacy default in KVM is based on the e500v1 TLB0 size, which is =20 half of what e500v2/e500mc have, and -3. QEMU needs to know the exact geometry of the TLB so that it can +3. QEMU needs to know the exact geometry of the TLB so that it can =20 interpret the shared data properly. -#3 seems like a compelling reason here, to avoid silent weirdness if -there's a slight mismatch between what QEMU thinks it's modelling and +#3 seems like a compelling reason here, to avoid silent weirdness if =20 +there's a slight mismatch between what QEMU thinks it's modelling and =20 what we're actually running on. --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index c30548b..6ebbf0e 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,12 +1,12 @@ "ref\0300B73AA675FCE4A93EB4FC1D42459FF2F7861@039-SN2MPN1-012.039d.mgd.msft.net\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier\0" - "Date\0Thu, 31 Jan 2013 16:48:24 +0000\0" + "Date\0Thu, 31 Jan 2013 10:48:24 -0600\0" "To\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>\0" - "Cc\0Alexander Graf <agraf@suse.de>" + "Cc\0linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>" + Alexander Graf <agraf@suse.de> kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org> - kvm@vger.kernel.org <kvm@vger.kernel.org> - " linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>\0" + " kvm@vger.kernel.org <kvm@vger.kernel.org>\0" "\00:1\0" "b\0" "On 01/31/2013 09:26:20 AM, Caraman Mihai Claudiu-B02008 wrote:\n" @@ -28,7 +28,7 @@ "> > >> To: Caraman Mihai Claudiu-B02008\n" "> > >> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-\n" "> > >> dev@lists.ozlabs.org\n" - "> > >> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG \n" + "> > >> Subject: Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG =20\n" "> register\n" "> > >> initialization earlier\n" "> > >>\n" @@ -39,9 +39,9 @@ "> > >> KVM_CAP_SW_TLB\n" "> > >>> ioctl call. Move it earlier into tlb initalization phase.\n" "> > >>\n" - "> > >> Quite the contrary. The fact that there is an mfspr() in \n" + "> > >> Quite the contrary. The fact that there is an mfspr() in =20\n" "> e500_mmu.c\n" - "> > >> already tells us that the code is broken. The TLB guest code \n" + "> > >> already tells us that the code is broken. The TLB guest code =20\n" "> should\n" "> > only\n" "> > >> depend on input from the SW_TLB configuration. It's completely\n" @@ -50,40 +50,40 @@ "> > >\n" "> > > Then we have the same issue for TLBnCFG registers which need to be\n" "> > configured\n" - "> > > via SW_TLB ioctl. What is the purpose of guest tlb initalization \n" + "> > > via SW_TLB ioctl. What is the purpose of guest tlb initalization =20\n" "> in\n" "> > e500_mmu.c\n" "> > > if we rely on SW_TLB?\n" "> >\n" - "> > It's to provide a fallback to user space that doesn't implement \n" + "> > It's to provide a fallback to user space that doesn't implement =20\n" "> SW_TLB\n" "> > configuration yet.\n" - "> \n" - "> Do we have such a case now or is it just hypothetical? For the \n" + ">=20\n" + "> Do we have such a case now or is it just hypothetical? For the =20\n" "> fallback we\n" - "> need to initialize the MMUCFG register which I intended to say in the \n" + "> need to initialize the MMUCFG register which I intended to say in the =20\n" "> commit\n" "> message.\n" "\n" - "I don't think we need to support a fallback for e6500, since there's \n" + "I don't think we need to support a fallback for e6500, since there's =20\n" "nothing to be backwards compatible with.\n" "\n" - "As for use case, I don't see us ever supporting the guest being a \n" - "different CPU than the host. Page sizes probably aren't a problem, but \n" + "As for use case, I don't see us ever supporting the guest being a =20\n" + "different CPU than the host. Page sizes probably aren't a problem, but =20\n" "there are other barriers.\n" "\n" "The main reasons that TLBnCFG are settable through SW_TLB are:\n" - "1. The guest TLB can be enlarged as a performance hack (like in Topaz, \n" + "1. The guest TLB can be enlarged as a performance hack (like in Topaz, =20\n" "though QEMU doesn't currently do this),\n" - "2. The legacy default in KVM is based on the e500v1 TLB0 size, which is \n" + "2. The legacy default in KVM is based on the e500v1 TLB0 size, which is =20\n" "half of what e500v2/e500mc have, and\n" - "3. QEMU needs to know the exact geometry of the TLB so that it can \n" + "3. QEMU needs to know the exact geometry of the TLB so that it can =20\n" "interpret the shared data properly.\n" "\n" - "#3 seems like a compelling reason here, to avoid silent weirdness if \n" - "there's a slight mismatch between what QEMU thinks it's modelling and \n" + "#3 seems like a compelling reason here, to avoid silent weirdness if =20\n" + "there's a slight mismatch between what QEMU thinks it's modelling and =20\n" "what we're actually running on.\n" "\n" - -Scott + -Scott= -d89b86872291ccdc8147bb9982c6122d0faa845f897c6a5e3c0aa6c29258c65b +b27b5a107c3194e5c00c0a3e4288b73e9bf8fb99c128480dc25304401828d831
diff --git a/a/content_digest b/N2/content_digest index c30548b..5c72514 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,7 +1,7 @@ "ref\0300B73AA675FCE4A93EB4FC1D42459FF2F7861@039-SN2MPN1-012.039d.mgd.msft.net\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 1/5] KVM: PPC: e500: Move VCPU's MMUCFG register initialization earlier\0" - "Date\0Thu, 31 Jan 2013 16:48:24 +0000\0" + "Date\0Thu, 31 Jan 2013 10:48:24 -0600\0" "To\0Caraman Mihai Claudiu-B02008 <B02008@freescale.com>\0" "Cc\0Alexander Graf <agraf@suse.de>" kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org> @@ -86,4 +86,4 @@ "\n" -Scott -d89b86872291ccdc8147bb9982c6122d0faa845f897c6a5e3c0aa6c29258c65b +d74f19e7ebff8aa5d9a1249896905a62e54ccdb7380b7bb550dcbb3d2256025a
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.