diff for duplicates of <1373414797.8183.212@snotra> diff --git a/a/1.txt b/N1/1.txt index 208143c..ada686a 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,45 +1,45 @@ On 07/09/2013 04:44:24 PM, Alexander Graf wrote: -> +>=20 > On 09.07.2013, at 20:46, Scott Wood wrote: -> > I suspect that tlbsx is faster, or at worst similar. And unlike -> comparing tlbsx to lwepx (not counting a fix for the threading -> problem), we don't already have code to search the guest TLB, so +> > I suspect that tlbsx is faster, or at worst similar. And unlike =20 +> comparing tlbsx to lwepx (not counting a fix for the threading =20 +> problem), we don't already have code to search the guest TLB, so =20 > testing would be more work. -> -> We have code to walk the guest TLB for TLB misses. This really is +>=20 +> We have code to walk the guest TLB for TLB misses. This really is =20 > just the TLB miss search without host TLB injection. -> -> So let's say we're using the shadow TLB. The guest always has its say -> 64 TLB entries that it can count on - we never evict anything by -> accident, because we store all of the 64 entries in our guest TLB -> cache. When the guest faults at an address, the first thing we do is +>=20 +> So let's say we're using the shadow TLB. The guest always has its say =20 +> 64 TLB entries that it can count on - we never evict anything by =20 +> accident, because we store all of the 64 entries in our guest TLB =20 +> cache. When the guest faults at an address, the first thing we do is =20 > we check the cache whether we have that page already mapped. -> -> However, with this method we now have 2 enumeration methods for guest -> TLB searches. We have the tlbsx one which searches the host TLB and -> we have our guest TLB cache. The guest TLB cache might still contain -> an entry for an address that we already invalidated on the host. +>=20 +> However, with this method we now have 2 enumeration methods for guest =20 +> TLB searches. We have the tlbsx one which searches the host TLB and =20 +> we have our guest TLB cache. The guest TLB cache might still contain =20 +> an entry for an address that we already invalidated on the host. =20 > Would that impose a problem? -> -> I guess not because we're swizzling the exit code around to instead -> be an instruction miss which means we restore the TLB entry into our -> host's TLB so that when we resume, we land here and the tlbsx hits. +>=20 +> I guess not because we're swizzling the exit code around to instead =20 +> be an instruction miss which means we restore the TLB entry into our =20 +> host's TLB so that when we resume, we land here and the tlbsx hits. =20 > But it feels backwards. -Any better way? Searching the guest TLB won't work for the LRAT case, -so we'd need to have this logic around anyway. We shouldn't add a -second codepath unless it's a clear performance gain -- and again, I -suspect it would be the opposite, especially if the entry is not in -TLB0 or in one of the first few entries searched in TLB1. The tlbsx +Any better way? Searching the guest TLB won't work for the LRAT case, =20 +so we'd need to have this logic around anyway. We shouldn't add a =20 +second codepath unless it's a clear performance gain -- and again, I =20 +suspect it would be the opposite, especially if the entry is not in =20 +TLB0 or in one of the first few entries searched in TLB1. The tlbsx =20 miss case is not what we should optimize for. -> At least this code has to become something more generic, such as -> kvmppc_read_guest(vcpu, addr, TYPE_INSN) and move into the host mmu +> At least this code has to become something more generic, such as =20 +> kvmppc_read_guest(vcpu, addr, TYPE_INSN) and move into the host mmu =20 > implementation, as it's 100% host mmu specific. -I agree that e500_mmu_host.c is a better place for it (with an ifdef -for BOOKEHV), but supporting anything other than instruction fetches -could wait until we have a user for it (it means extra code to figure +I agree that e500_mmu_host.c is a better place for it (with an ifdef =20 +for BOOKEHV), but supporting anything other than instruction fetches =20 +could wait until we have a user for it (it means extra code to figure =20 out if permissions are correct). --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index 4760cef..9671901 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,58 +1,58 @@ "ref\0BD85AACF-5975-459D-9D28-8DB672D6B5C3@suse.de\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 2/2] KVM: PPC: Book3E: Get vcpu's last instruction for emulation\0" - "Date\0Wed, 10 Jul 2013 00:06:37 +0000\0" + "Date\0Tue, 9 Jul 2013 19:06:37 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Mihai Caraman <mihai.caraman@freescale.com>" - kvm-ppc@vger.kernel.org + linuxppc-dev@lists.ozlabs.org kvm@vger.kernel.org - " linuxppc-dev@lists.ozlabs.org\0" + " kvm-ppc@vger.kernel.org\0" "\00:1\0" "b\0" "On 07/09/2013 04:44:24 PM, Alexander Graf wrote:\n" - "> \n" + ">=20\n" "> On 09.07.2013, at 20:46, Scott Wood wrote:\n" - "> > I suspect that tlbsx is faster, or at worst similar. And unlike \n" - "> comparing tlbsx to lwepx (not counting a fix for the threading \n" - "> problem), we don't already have code to search the guest TLB, so \n" + "> > I suspect that tlbsx is faster, or at worst similar. And unlike =20\n" + "> comparing tlbsx to lwepx (not counting a fix for the threading =20\n" + "> problem), we don't already have code to search the guest TLB, so =20\n" "> testing would be more work.\n" - "> \n" - "> We have code to walk the guest TLB for TLB misses. This really is \n" + ">=20\n" + "> We have code to walk the guest TLB for TLB misses. This really is =20\n" "> just the TLB miss search without host TLB injection.\n" - "> \n" - "> So let's say we're using the shadow TLB. The guest always has its say \n" - "> 64 TLB entries that it can count on - we never evict anything by \n" - "> accident, because we store all of the 64 entries in our guest TLB \n" - "> cache. When the guest faults at an address, the first thing we do is \n" + ">=20\n" + "> So let's say we're using the shadow TLB. The guest always has its say =20\n" + "> 64 TLB entries that it can count on - we never evict anything by =20\n" + "> accident, because we store all of the 64 entries in our guest TLB =20\n" + "> cache. When the guest faults at an address, the first thing we do is =20\n" "> we check the cache whether we have that page already mapped.\n" - "> \n" - "> However, with this method we now have 2 enumeration methods for guest \n" - "> TLB searches. We have the tlbsx one which searches the host TLB and \n" - "> we have our guest TLB cache. The guest TLB cache might still contain \n" - "> an entry for an address that we already invalidated on the host. \n" + ">=20\n" + "> However, with this method we now have 2 enumeration methods for guest =20\n" + "> TLB searches. We have the tlbsx one which searches the host TLB and =20\n" + "> we have our guest TLB cache. The guest TLB cache might still contain =20\n" + "> an entry for an address that we already invalidated on the host. =20\n" "> Would that impose a problem?\n" - "> \n" - "> I guess not because we're swizzling the exit code around to instead \n" - "> be an instruction miss which means we restore the TLB entry into our \n" - "> host's TLB so that when we resume, we land here and the tlbsx hits. \n" + ">=20\n" + "> I guess not because we're swizzling the exit code around to instead =20\n" + "> be an instruction miss which means we restore the TLB entry into our =20\n" + "> host's TLB so that when we resume, we land here and the tlbsx hits. =20\n" "> But it feels backwards.\n" "\n" - "Any better way? Searching the guest TLB won't work for the LRAT case, \n" - "so we'd need to have this logic around anyway. We shouldn't add a \n" - "second codepath unless it's a clear performance gain -- and again, I \n" - "suspect it would be the opposite, especially if the entry is not in \n" - "TLB0 or in one of the first few entries searched in TLB1. The tlbsx \n" + "Any better way? Searching the guest TLB won't work for the LRAT case, =20\n" + "so we'd need to have this logic around anyway. We shouldn't add a =20\n" + "second codepath unless it's a clear performance gain -- and again, I =20\n" + "suspect it would be the opposite, especially if the entry is not in =20\n" + "TLB0 or in one of the first few entries searched in TLB1. The tlbsx =20\n" "miss case is not what we should optimize for.\n" "\n" - "> At least this code has to become something more generic, such as \n" - "> kvmppc_read_guest(vcpu, addr, TYPE_INSN) and move into the host mmu \n" + "> At least this code has to become something more generic, such as =20\n" + "> kvmppc_read_guest(vcpu, addr, TYPE_INSN) and move into the host mmu =20\n" "> implementation, as it's 100% host mmu specific.\n" "\n" - "I agree that e500_mmu_host.c is a better place for it (with an ifdef \n" - "for BOOKEHV), but supporting anything other than instruction fetches \n" - "could wait until we have a user for it (it means extra code to figure \n" + "I agree that e500_mmu_host.c is a better place for it (with an ifdef =20\n" + "for BOOKEHV), but supporting anything other than instruction fetches =20\n" + "could wait until we have a user for it (it means extra code to figure =20\n" "out if permissions are correct).\n" "\n" - -Scott + -Scott= -ad8ceb893eb93babc92a17d3258c9a9aff450d4b48f038a02229d9c8c10b3ff8 +e90f0ba2f0230154f5de85b2ea123db51498eb42e10a2a720ae41453b8ee04ef
diff --git a/a/content_digest b/N2/content_digest index 4760cef..38eec32 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,12 +1,12 @@ "ref\0BD85AACF-5975-459D-9D28-8DB672D6B5C3@suse.de\0" "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 2/2] KVM: PPC: Book3E: Get vcpu's last instruction for emulation\0" - "Date\0Wed, 10 Jul 2013 00:06:37 +0000\0" + "Date\0Tue, 9 Jul 2013 19:06:37 -0500\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0Mihai Caraman <mihai.caraman@freescale.com>" - kvm-ppc@vger.kernel.org - kvm@vger.kernel.org - " linuxppc-dev@lists.ozlabs.org\0" + <kvm-ppc@vger.kernel.org> + <kvm@vger.kernel.org> + " <linuxppc-dev@lists.ozlabs.org>\0" "\00:1\0" "b\0" "On 07/09/2013 04:44:24 PM, Alexander Graf wrote:\n" @@ -55,4 +55,4 @@ "\n" -Scott -ad8ceb893eb93babc92a17d3258c9a9aff450d4b48f038a02229d9c8c10b3ff8 +c4093b6fcbc871f6ddc1f8f4d93db1f13eade62d43dd823ac6c6ebe3a7c32d0c
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.