diff for duplicates of <1399072472827.57968@freescale.com> diff --git a/a/1.txt b/N1/1.txt index 88ae47f..020aa54 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,41 +1,51 @@ -> From: Alexander Graf <agraf@suse.de> -> Sent: Friday, May 2, 2014 12:24 PM -> To: Caraman Mihai Claudiu-B02008 -> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-dev@lists.ozlabs.org -> Subject: Re: [PATCH v2 1/4] KVM: PPC: e500mc: Revert "add load inst fixup" -> -> On 05/01/2014 02:45 AM, Mihai Caraman wrote: -> > The commit 1d628af7 "add load inst fixup" made an attempt to handle -> > failures generated by reading the guest current instruction. The fixup -> > code that was added works by chance hiding the real issue. -> > -> > Load external pid (lwepx) instruction, used by KVM to read guest -> > instructions, is executed in a subsituted guest translation context -> > (EPLC[EGS] = 1). In consequence lwepx's TLB error and data storage -> > interrupts need to be handled by KVM, even though these interrupts -> > are generated from host context (MSR[GS] = 0). -> > -> > Currently, KVM hooks only interrupts generated from guest context -> > (MSR[GS] = 1), doing minimal checks on the fast path to avoid host -> > performance degradation. As a result, the host kernel handles lwepx -> > faults searching the faulting guest data address (loaded in DEAR) in -> > its own Logical Partition ID (LPID) 0 context. In case a host translation -> > is found the execution returns to the lwepx instruction instead of the -> > fixup, the host ending up in an infinite loop. -> > -> > Revert the commit "add load inst fixup". lwepx issue will be addressed -> > in a subsequent patch without needing fixup code. -> > -> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com> -> -> Just a random idea: Could we just switch IVOR2 during the critical lwepx -> phase? In fact, we could even do that later when we're already in C code -> and try to recover the last instruction. The code IVOR2 would point to -> would simply set the register we're trying to read to as LAST_INST_FAIL -> and rfi. - -This was the first idea that sprang to my mind inspired from how DO_KVM -is hooked on PR. I actually did a simple POC for e500mc/e5500, but this will -not work on e6500 which has shared IVORs between HW threads. - --Mike +> From: Alexander Graf <agraf@suse.de>=0A= +> Sent: Friday, May 2, 2014 12:24 PM=0A= +> To: Caraman Mihai Claudiu-B02008=0A= +> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-dev@lists.ozla= +bs.org=0A= +> Subject: Re: [PATCH v2 1/4] KVM: PPC: e500mc: Revert "add load inst fixup= +"=0A= +> =0A= +> On 05/01/2014 02:45 AM, Mihai Caraman wrote:=0A= +> > The commit 1d628af7 "add load inst fixup" made an attempt to handle=0A= +> > failures generated by reading the guest current instruction. The fixup= +=0A= +> > code that was added works by chance hiding the real issue.=0A= +> >=0A= +> > Load external pid (lwepx) instruction, used by KVM to read guest=0A= +> > instructions, is executed in a subsituted guest translation context=0A= +> > (EPLC[EGS] =3D 1). In consequence lwepx's TLB error and data storage=0A= +> > interrupts need to be handled by KVM, even though these interrupts=0A= +> > are generated from host context (MSR[GS] =3D 0).=0A= +> >=0A= +> > Currently, KVM hooks only interrupts generated from guest context=0A= +> > (MSR[GS] =3D 1), doing minimal checks on the fast path to avoid host=0A= +> > performance degradation. As a result, the host kernel handles lwepx=0A= +> > faults searching the faulting guest data address (loaded in DEAR) in=0A= +> > its own Logical Partition ID (LPID) 0 context. In case a host translati= +on=0A= +> > is found the execution returns to the lwepx instruction instead of the= +=0A= +> > fixup, the host ending up in an infinite loop.=0A= +> >=0A= +> > Revert the commit "add load inst fixup". lwepx issue will be addressed= +=0A= +> > in a subsequent patch without needing fixup code.=0A= +> >=0A= +> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>=0A= +> =0A= +> Just a random idea: Could we just switch IVOR2 during the critical lwepx= +=0A= +> phase? In fact, we could even do that later when we're already in C code= +=0A= +> and try to recover the last instruction. The code IVOR2 would point to=0A= +> would simply set the register we're trying to read to as LAST_INST_FAIL= +=0A= +> and rfi.=0A= +=0A= +This was the first idea that sprang to my mind inspired from how DO_KVM=0A= +is hooked on PR. I actually did a simple POC for e500mc/e5500, but this wil= +l=0A= +not work on e6500 which has shared IVORs between HW threads.=0A= +=0A= +-Mike= diff --git a/a/content_digest b/N1/content_digest index 99d13ee..a0ffbed 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,53 +3,63 @@ "ref\053636436.60002@suse.de\0" "From\0mihai.caraman@freescale.com <mihai.caraman@freescale.com>\0" "Subject\0RE: [PATCH v2 1/4] KVM: PPC: e500mc: Revert \"add load inst fixup\"\0" - "Date\0Fri, 02 May 2014 23:14:29 +0000\0" + "Date\0Fri, 2 May 2014 23:14:29 +0000\0" "To\0Alexander Graf <agraf@suse.de>\0" - "Cc\0kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org>" + "Cc\0linuxppc-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" - "> From: Alexander Graf <agraf@suse.de>\n" - "> Sent: Friday, May 2, 2014 12:24 PM\n" - "> To: Caraman Mihai Claudiu-B02008\n" - "> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-dev@lists.ozlabs.org\n" - "> Subject: Re: [PATCH v2 1/4] KVM: PPC: e500mc: Revert \"add load inst fixup\"\n" - "> \n" - "> On 05/01/2014 02:45 AM, Mihai Caraman wrote:\n" - "> > The commit 1d628af7 \"add load inst fixup\" made an attempt to handle\n" - "> > failures generated by reading the guest current instruction. The fixup\n" - "> > code that was added works by chance hiding the real issue.\n" - "> >\n" - "> > Load external pid (lwepx) instruction, used by KVM to read guest\n" - "> > instructions, is executed in a subsituted guest translation context\n" - "> > (EPLC[EGS] = 1). In consequence lwepx's TLB error and data storage\n" - "> > interrupts need to be handled by KVM, even though these interrupts\n" - "> > are generated from host context (MSR[GS] = 0).\n" - "> >\n" - "> > Currently, KVM hooks only interrupts generated from guest context\n" - "> > (MSR[GS] = 1), doing minimal checks on the fast path to avoid host\n" - "> > performance degradation. As a result, the host kernel handles lwepx\n" - "> > faults searching the faulting guest data address (loaded in DEAR) in\n" - "> > its own Logical Partition ID (LPID) 0 context. In case a host translation\n" - "> > is found the execution returns to the lwepx instruction instead of the\n" - "> > fixup, the host ending up in an infinite loop.\n" - "> >\n" - "> > Revert the commit \"add load inst fixup\". lwepx issue will be addressed\n" - "> > in a subsequent patch without needing fixup code.\n" - "> >\n" - "> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>\n" - "> \n" - "> Just a random idea: Could we just switch IVOR2 during the critical lwepx\n" - "> phase? In fact, we could even do that later when we're already in C code\n" - "> and try to recover the last instruction. The code IVOR2 would point to\n" - "> would simply set the register we're trying to read to as LAST_INST_FAIL\n" - "> and rfi.\n" - "\n" - "This was the first idea that sprang to my mind inspired from how DO_KVM\n" - "is hooked on PR. I actually did a simple POC for e500mc/e5500, but this will\n" - "not work on e6500 which has shared IVORs between HW threads.\n" - "\n" - -Mike + "> From: Alexander Graf <agraf@suse.de>=0A=\n" + "> Sent: Friday, May 2, 2014 12:24 PM=0A=\n" + "> To: Caraman Mihai Claudiu-B02008=0A=\n" + "> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-dev@lists.ozla=\n" + "bs.org=0A=\n" + "> Subject: Re: [PATCH v2 1/4] KVM: PPC: e500mc: Revert \"add load inst fixup=\n" + "\"=0A=\n" + "> =0A=\n" + "> On 05/01/2014 02:45 AM, Mihai Caraman wrote:=0A=\n" + "> > The commit 1d628af7 \"add load inst fixup\" made an attempt to handle=0A=\n" + "> > failures generated by reading the guest current instruction. The fixup=\n" + "=0A=\n" + "> > code that was added works by chance hiding the real issue.=0A=\n" + "> >=0A=\n" + "> > Load external pid (lwepx) instruction, used by KVM to read guest=0A=\n" + "> > instructions, is executed in a subsituted guest translation context=0A=\n" + "> > (EPLC[EGS] =3D 1). In consequence lwepx's TLB error and data storage=0A=\n" + "> > interrupts need to be handled by KVM, even though these interrupts=0A=\n" + "> > are generated from host context (MSR[GS] =3D 0).=0A=\n" + "> >=0A=\n" + "> > Currently, KVM hooks only interrupts generated from guest context=0A=\n" + "> > (MSR[GS] =3D 1), doing minimal checks on the fast path to avoid host=0A=\n" + "> > performance degradation. As a result, the host kernel handles lwepx=0A=\n" + "> > faults searching the faulting guest data address (loaded in DEAR) in=0A=\n" + "> > its own Logical Partition ID (LPID) 0 context. In case a host translati=\n" + "on=0A=\n" + "> > is found the execution returns to the lwepx instruction instead of the=\n" + "=0A=\n" + "> > fixup, the host ending up in an infinite loop.=0A=\n" + "> >=0A=\n" + "> > Revert the commit \"add load inst fixup\". lwepx issue will be addressed=\n" + "=0A=\n" + "> > in a subsequent patch without needing fixup code.=0A=\n" + "> >=0A=\n" + "> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>=0A=\n" + "> =0A=\n" + "> Just a random idea: Could we just switch IVOR2 during the critical lwepx=\n" + "=0A=\n" + "> phase? In fact, we could even do that later when we're already in C code=\n" + "=0A=\n" + "> and try to recover the last instruction. The code IVOR2 would point to=0A=\n" + "> would simply set the register we're trying to read to as LAST_INST_FAIL=\n" + "=0A=\n" + "> and rfi.=0A=\n" + "=0A=\n" + "This was the first idea that sprang to my mind inspired from how DO_KVM=0A=\n" + "is hooked on PR. I actually did a simple POC for e500mc/e5500, but this wil=\n" + "l=0A=\n" + "not work on e6500 which has shared IVORs between HW threads.=0A=\n" + "=0A=\n" + -Mike= -515335b8efdae3f8db95a2897f314c49249be4b6caa2772e6a30e5840df68438 +62448d6072b755d27cb219c634cc320f416a176ad723e7f2fd5b16c5f44e2405
diff --git a/a/content_digest b/N2/content_digest index 99d13ee..c55024d 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -3,7 +3,7 @@ "ref\053636436.60002@suse.de\0" "From\0mihai.caraman@freescale.com <mihai.caraman@freescale.com>\0" "Subject\0RE: [PATCH v2 1/4] KVM: PPC: e500mc: Revert \"add load inst fixup\"\0" - "Date\0Fri, 02 May 2014 23:14:29 +0000\0" + "Date\0Fri, 2 May 2014 23:14:29 +0000\0" "To\0Alexander Graf <agraf@suse.de>\0" "Cc\0kvm-ppc@vger.kernel.org <kvm-ppc@vger.kernel.org>" kvm@vger.kernel.org <kvm@vger.kernel.org> @@ -52,4 +52,4 @@ "\n" -Mike -515335b8efdae3f8db95a2897f314c49249be4b6caa2772e6a30e5840df68438 +70af0b4b7cc12976358a053b61682980f3eafe67226e599567b77983bde1d2bc
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.