All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Mihai Caraman <mihai.caraman@freescale.com>
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"
Date: Fri, 02 May 2014 09:24:06 +0000	[thread overview]
Message-ID: <53636436.60002@suse.de> (raw)
In-Reply-To: <1398905152-18091-2-git-send-email-mihai.caraman@freescale.com>

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.


Alex


WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Mihai Caraman <mihai.caraman@freescale.com>
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
	kvm-ppc@vger.kernel.org
Subject: Re: [PATCH v2 1/4] KVM: PPC: e500mc: Revert "add load inst fixup"
Date: Fri, 02 May 2014 11:24:06 +0200	[thread overview]
Message-ID: <53636436.60002@suse.de> (raw)
In-Reply-To: <1398905152-18091-2-git-send-email-mihai.caraman@freescale.com>

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.


Alex

WARNING: multiple messages have this Message-ID (diff)
From: Alexander Graf <agraf@suse.de>
To: Mihai Caraman <mihai.caraman@freescale.com>
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"
Date: Fri, 02 May 2014 11:24:06 +0200	[thread overview]
Message-ID: <53636436.60002@suse.de> (raw)
In-Reply-To: <1398905152-18091-2-git-send-email-mihai.caraman@freescale.com>

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.


Alex

  reply	other threads:[~2014-05-02  9:24 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-01  0:39 [PATCH v2 0/4] KVM: PPC: Read guest instruction from kvmppc_get_last_inst() Mihai Caraman
2014-05-01  0:39 ` Mihai Caraman
2014-05-01  0:39 ` Mihai Caraman
2014-05-01  0:45 ` Mihai Caraman
2014-05-01  0:45   ` Mihai Caraman
2014-05-01  0:45   ` Mihai Caraman
2014-05-01  0:45   ` [PATCH v2 1/4] KVM: PPC: e500mc: Revert "add load inst fixup" Mihai Caraman
2014-05-01  0:45     ` Mihai Caraman
2014-05-01  0:45     ` Mihai Caraman
2014-05-02  9:24     ` Alexander Graf [this message]
2014-05-02  9:24       ` Alexander Graf
2014-05-02  9:24       ` Alexander Graf
2014-05-02 23:14       ` mihai.caraman
2014-05-02 23:14         ` mihai.caraman
2014-05-02 23:14         ` mihai.caraman
2014-05-03 22:14         ` Alexander Graf
2014-05-03 22:14           ` Alexander Graf
2014-05-03 22:14           ` Alexander Graf
2014-05-06 15:48           ` mihai.caraman
2014-05-06 15:48             ` mihai.caraman
2014-05-06 15:48             ` mihai.caraman
2014-05-06 15:54             ` Alexander Graf
2014-05-06 15:54               ` Alexander Graf
2014-05-06 15:54               ` Alexander Graf
2014-05-01  0:45   ` [PATCH v2 2/4] KVM: PPC: Book3e: Add TLBSEL/TSIZE defines for MAS0/1 Mihai Caraman
2014-05-01  0:45     ` Mihai Caraman
2014-05-01  0:45     ` Mihai Caraman
2014-05-01  0:45   ` [PATCH v2 3/4] KVM: PPC: Alow kvmppc_get_last_inst() to fail Mihai Caraman
2014-05-01  0:45     ` Mihai Caraman
2014-05-01  0:45     ` Mihai Caraman
2014-05-02  9:54     ` Alexander Graf
2014-05-02  9:54       ` Alexander Graf
2014-05-02  9:54       ` Alexander Graf
2014-05-06 19:06       ` mihai.caraman
2014-05-06 19:06         ` mihai.caraman
2014-05-06 19:06         ` mihai.caraman
2014-05-08 13:31         ` Alexander Graf
2014-05-08 13:31           ` Alexander Graf
2014-05-08 13:31           ` Alexander Graf
2014-05-01  0:45   ` [PATCH v2 4/4] KVM: PPC: Bookehv: Get vcpu's last instruction for emulation Mihai Caraman
2014-05-01  0:45     ` Mihai Caraman
2014-05-01  0:45     ` Mihai Caraman
2014-05-02 10:01     ` Alexander Graf
2014-05-02 10:01       ` Alexander Graf
2014-05-02 10:01       ` Alexander Graf
2014-05-02 10:12       ` David Laight
2014-05-02 10:12         ` David Laight
2014-05-02 10:12         ` David Laight
2014-05-02 11:10         ` Alexander Graf
2014-05-02 11:10           ` Alexander Graf
2014-05-02 11:10           ` Alexander Graf
2014-05-02 15:32           ` Scott Wood
2014-05-02 15:32             ` Scott Wood
2014-05-02 15:32             ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53636436.60002@suse.de \
    --to=agraf@suse.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mihai.caraman@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.