From patchwork Wed Mar 20 17:45:57 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bharat Bhushan X-Patchwork-Id: 229443 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from ozlabs.org (localhost [IPv6:::1]) by ozlabs.org (Postfix) with ESMTP id 234B42C04DF for ; Thu, 21 Mar 2013 04:47:47 +1100 (EST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "Microsoft Secure Server Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id E06132C00BE for ; Thu, 21 Mar 2013 04:47:19 +1100 (EST) Received: from mail129-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE012.bigfish.com (10.236.130.75) with Microsoft SMTP Server id 14.1.225.23; Wed, 20 Mar 2013 17:47:15 +0000 Received: from mail129-co9 (localhost [127.0.0.1]) by mail129-co9-R.bigfish.com (Postfix) with ESMTP id 8377D3A0165; Wed, 20 Mar 2013 17:47:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VS3(zzzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz8275bhz2dh2a8h668h839he5bhf0ah107ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1155h) Received: from mail129-co9 (localhost.localdomain [127.0.0.1]) by mail129-co9 (MessageSwitch) id 1363801634268019_14742; Wed, 20 Mar 2013 17:47:14 +0000 (UTC) Received: from CO9EHSMHS002.bigfish.com (unknown [10.236.132.226]) by mail129-co9.bigfish.com (Postfix) with ESMTP id 3050C380070; Wed, 20 Mar 2013 17:47:14 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by CO9EHSMHS002.bigfish.com (10.236.130.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 20 Mar 2013 17:47:13 +0000 Received: from tx30smr01.am.freescale.net (10.81.153.31) by 039-SN1MMR1-002.039d.mgd.msft.net (10.84.1.15) with Microsoft SMTP Server (TLS) id 14.2.328.11; Wed, 20 Mar 2013 17:47:13 +0000 Received: from freescale.com ([10.232.15.72]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with SMTP id r2KHl8g2019015; Wed, 20 Mar 2013 10:47:09 -0700 Received: by freescale.com (sSMTP sendmail emulation); Wed, 20 Mar 2013 23:15:59 +0530 From: Bharat Bhushan To: , , , , Subject: [PATCH] bookehv: Handle debug exception on guest exit Date: Wed, 20 Mar 2013 23:15:57 +0530 Message-ID: <1363801557-27436-1-git-send-email-Bharat.Bhushan@freescale.com> X-Mailer: git-send-email 1.7.0.4 MIME-Version: 1.0 X-OriginatorOrg: freescale.com Cc: Bharat Bhushan X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" 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 = 1) to hypervisor mode (MSR.GS = 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. This is tested on e500mc in 32 bit mode Signed-off-by: Bharat Bhushan --- v0: - Do not apply this change for debug_crit as we do not know those chips have issue or not. - corrected 64bit case branching arch/powerpc/kernel/exceptions-64e.S | 29 ++++++++++++++++++++++++++++- arch/powerpc/kernel/head_booke.h | 26 ++++++++++++++++++++++++++ 2 files changed, 54 insertions(+), 1 deletions(-) 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 +#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 = 1) to hypervisor + * mode (MSR.GS = 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+ 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 - /* 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 = 1) to hypervisor \ + * mode (MSR.GS = 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; \