LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Bharat Bhushan <r65777@freescale.com>
Cc: scottwood@freescale.com,
	Bharat Bhushan <Bharat.Bhushan@freescale.com>,
	linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
	kvm@vger.kernel.org
Subject: Re: [PATCH] bookehv: Handle debug exception on guest exit
Date: Thu, 4 Apr 2013 15:25:28 +0200	[thread overview]
Message-ID: <436085E0-D605-40C1-BCDF-EB4D24B01AFA@suse.de> (raw)
In-Reply-To: <1363801557-27436-1-git-send-email-Bharat.Bhushan@freescale.com>


On 20.03.2013, at 18:45, Bharat Bhushan wrote:

> EPCR.DUVD controls whether the debug events can come in
> hypervisor mode or not. When KVM guest is using the debug
> resource then we do not want debug events to be captured
> in guest entry/exit path. So we set EPCR.DUVD when entering
> and clears EPCR.DUVD when exiting from guest.
>=20
> Debug instruction complete is a post-completion debug
> exception but debug event gets posted on the basis of MSR
> before the instruction is executed. Now if the instruction
> switches the context from guest mode (MSR.GS =3D 1) to hypervisor
> mode (MSR.GS =3D 0) then the xSRR0 points to first instruction of
> KVM handler and xSRR1 points that MSR.GS is clear
> (hypervisor context). Now as xSRR1.GS is used to decide whether
> KVM handler will be invoked to handle the exception or host
> host kernel debug handler will be invoked to handle the exception.
> This leads to host kernel debug handler handling the exception
> which should either be handled by KVM.
>=20
> This is tested on e500mc in 32 bit mode
>=20
> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
> ---
> v0:
> - Do not apply this change for debug_crit as we do not know those =
chips have issue or not.
> - corrected 64bit case branching
>=20
> arch/powerpc/kernel/exceptions-64e.S |   29 =
++++++++++++++++++++++++++++-
> arch/powerpc/kernel/head_booke.h     |   26 ++++++++++++++++++++++++++
> 2 files changed, 54 insertions(+), 1 deletions(-)
>=20
> diff --git a/arch/powerpc/kernel/exceptions-64e.S =
b/arch/powerpc/kernel/exceptions-64e.S
> index 4684e33..8b26294 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -516,6 +516,33 @@ kernel_dbg_exc:
> 	andis.	r15,r14,DBSR_IC@h
> 	beq+	1f
>=20
> +#ifdef CONFIG_KVM_BOOKE_HV
> +	/*
> +	 * EPCR.DUVD controls whether the debug events can come in
> +	 * hypervisor mode or not. When KVM guest is using the debug
> +	 * resource then we do not want debug events to be captured
> +	 * in guest entry/exit path. So we set EPCR.DUVD when entering
> +	 * and clears EPCR.DUVD when exiting from guest.
> +	 * Debug instruction complete is a post-completion debug
> +	 * exception but debug event gets posted on the basis of MSR
> +	 * before the instruction is executed. Now if the instruction
> +	 * switches the context from guest mode (MSR.GS =3D 1) to =
hypervisor
> +	 * mode (MSR.GS =3D 0) then the xSRR0 points to first =
instruction of

Can't we just execute that code path with MSR.DE=3D0?


Alex

> +	 * KVM handler and xSRR1 points that MSR.GS is clear
> +	 * (hypervisor context). Now as xSRR1.GS is used to decide =
whether
> +	 * KVM handler will be invoked to handle the exception or host
> +	 * host kernel debug handler will be invoked to handle the =
exception.
> +	 * This leads to host kernel debug handler handling the =
exception
> +	 * which should either be handled by KVM.
> +	 */
> +	mfspr	r10, SPRN_EPCR
> +	andis.	r10,r10,SPRN_EPCR_DUVD@h
> +	beq+	2f
> +
> +	andis.	r10,r9,MSR_GS@h
> +	beq+	3f
> +2:
> +#endif
> 	LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e)
> 	LOAD_REG_IMMEDIATE(r15,interrupt_end_book3e)
> 	cmpld	cr0,r10,r14
> @@ -523,7 +550,7 @@ kernel_dbg_exc:
> 	blt+	cr0,1f
> 	bge+	cr1,1f
>=20
> -	/* here it looks like we got an inappropriate debug exception. =
*/
> +3:	/* here it looks like we got an inappropriate debug exception. =
*/
> 	lis	r14,DBSR_IC@h		/* clear the IC event */
> 	rlwinm	r11,r11,0,~MSR_DE	/* clear DE in the DSRR1 value =
*/
> 	mtspr	SPRN_DBSR,r14
> diff --git a/arch/powerpc/kernel/head_booke.h =
b/arch/powerpc/kernel/head_booke.h
> index 5f051ee..edc6a3b 100644
> --- a/arch/powerpc/kernel/head_booke.h
> +++ b/arch/powerpc/kernel/head_booke.h
> @@ -285,7 +285,33 @@ label:
> 	mfspr	r10,SPRN_DBSR;		/* check single-step/branch =
taken */  \
> 	andis.	r10,r10,(DBSR_IC|DBSR_BT)@h;				 =
     \
> 	beq+	2f;							 =
     \
> +#ifdef CONFIG_KVM_BOOKE_HV						 =
     \
> +	/*								 =
     \
> +	 * EPCR.DUVD controls whether the debug events can come in	 =
     \
> +	 * hypervisor mode or not. When KVM guest is using the debug	 =
     \
> +	 * resource then we do not want debug events to be captured 	 =
     \
> +	 * in guest entry/exit path. So we set EPCR.DUVD when entering	 =
     \
> +	 * and clears EPCR.DUVD when exiting from guest.		 =
     \
> +	 * Debug instruction complete is a post-completion debug	 =
     \
> +	 * exception but debug event gets posted on the basis of MSR	 =
     \
> +	 * before the instruction is executed. Now if the instruction	 =
     \
> +	 * switches the context from guest mode (MSR.GS =3D 1) to =
hypervisor    \
> +	 * mode (MSR.GS =3D 0) then the xSRR0 points to first =
instruction of    \
> +	 * KVM handler and xSRR1 points that MSR.GS is clear 		 =
     \
> +	 * (hypervisor context). Now as xSRR1.GS is used to decide =
whether    \
> +	 * KVM handler will be invoked to handle the exception or host	 =
     \
> +	 * host kernel debug handler will be invoked to handle the =
exception. \
> +	 * This leads to host kernel debug handler handling the =
exception     \
> +	 * which should either be handled by KVM.			 =
     \
> +	 */								 =
     \
> +	mfspr	r10, SPRN_EPCR;						 =
     \
> +	andis.	r10,r10,SPRN_EPCR_DUVD@h;				 =
     \
> +	beq+	3f;							 =
     \
> 									 =
     \
> +	andis.	r10,r9,MSR_GS@h;				    	 =
     \
> +	beq+	1f;							 =
     \
> +3:									 =
     \
> +#endif									=
      \
> 	lis	r10,KERNELBASE@h;	/* check if exception in vectors =
*/   \
> 	ori	r10,r10,KERNELBASE@l;					 =
     \
> 	cmplw	r12,r10;						 =
     \
> --=20
> 1.7.0.4
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-04-04 13:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 17:45 [PATCH] bookehv: Handle debug exception on guest exit Bharat Bhushan
2013-04-04 13:25 ` Alexander Graf [this message]
2013-04-04 14:58   ` Bhushan Bharat-R65777
2013-04-05  7:53     ` Bhushan Bharat-R65777
2013-04-11 18:33       ` Kumar Gala
2013-04-11 18:37         ` Stuart Yoder
2013-04-11 18:44           ` Stuart Yoder

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=436085E0-D605-40C1-BCDF-EB4D24B01AFA@suse.de \
    --to=agraf@suse.de \
    --cc=Bharat.Bhushan@freescale.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=r65777@freescale.com \
    --cc=scottwood@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox