[PATCH 0/6] Guest debug emulation

[PATCH 0/6] Guest debug emulation

[Bharat Bhushan]

This patchset adds debug register and interrupt emulation support
for guest, which enables running gdb/kgdb etc in guest.
This also have couple of bux fixes

Bharat Bhushan (6):
  KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register
  KVM: PPC: BOOKE: Force MSR_DE in rfci if guest is under debug
  KVM: PPC: BOOKE: allow debug interrupt at "debug level"
  KVM: PPC: BOOKE : Emulate rfdi instruction
  KVM: PPC: BOOKE: Allow guest to change MSR_DE
  KVM: PPC: BOOKE: Emulate debug registers and exception

 arch/powerpc/include/asm/kvm_host.h |   1 +
 arch/powerpc/include/asm/kvm_ppc.h  |   3 +
 arch/powerpc/kvm/booke.c            |  35 ++++++-
 arch/powerpc/kvm/booke_emulate.c    | 180 +++++++++++++++++++++++++++++++++++-
 arch/powerpc/kvm/e500mc.c           |   2 +-
 5 files changed, 216 insertions(+), 5 deletions(-)

-- 
1.9.3

[PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Bharat Bhushan]

This is not used and  even I do not remember why this was added
in first place.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/kvm/booke.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index ab62109..a5ee42c 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1804,8 +1804,6 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
 	kvm_guest_protect_msr(vcpu, MSR_DE, true);
 	vcpu->guest_debug = dbg->control;
 	vcpu->arch.shadow_dbg_reg.dbcr0 = 0;
-	/* Set DBCR0_EDM in guest visible DBCR0 register. */
-	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
 
 	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
 		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC;
-- 
1.9.3

[PATCH 2/6] KVM: PPC: BOOKE: Force MSR_DE in rfci if guest is under debug

[Bharat Bhushan]

When userspace (QEMU) is using the debug resource to debug guest
then we want MSR_DE to be always set. This patch adds missing
MSR_DE setting in "rfci" instruction.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/kvm/booke_emulate.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
index 27a4b28..80c51a2 100644
--- a/arch/powerpc/kvm/booke_emulate.c
+++ b/arch/powerpc/kvm/booke_emulate.c
@@ -40,7 +40,11 @@ static void kvmppc_emul_rfi(struct kvm_vcpu *vcpu)
 static void kvmppc_emul_rfci(struct kvm_vcpu *vcpu)
 {
 	vcpu->arch.pc = vcpu->arch.csrr0;
-	kvmppc_set_msr(vcpu, vcpu->arch.csrr1);
+	/* Force MSR_DE when guest does not own debug facilities */
+	if (vcpu->guest_debug)
+		kvmppc_set_msr(vcpu, vcpu->arch.csrr1 | MSR_DE);
+	else
+		kvmppc_set_msr(vcpu, vcpu->arch.csrr1);
 }
 
 int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
-- 
1.9.3

[PATCH 3/6] KVM: PPC: BOOKE: allow debug interrupt at "debug level"

[Bharat Bhushan]

Debug interrupt can be either "critical level" or "debug level".
There are separate set of save/restore registers used for different level.
Example: DSRR0/DSRR1 are used for "debug level" and CSRR0/CSRR1
are used for critical level debug interrupt.

Using CPU_FTR_DEBUG_LVL_EXC to decide which interrupt level to be used.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/kvm/booke.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index a5ee42c..fadfe76 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -424,7 +424,11 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu,
 		allowed = vcpu->arch.shared->msr & MSR_DE;
 		allowed = allowed && !crit;
 		msr_mask = MSR_ME;
-		int_class = INT_CLASS_CRIT;
+		if (cpu_has_feature(CPU_FTR_DEBUG_LVL_EXC))
+			int_class = INT_CLASS_DBG;
+		else
+			int_class = INT_CLASS_CRIT;
+
 		break;
 	}
 
-- 
1.9.3

[PATCH 4/6] KVM: PPC: BOOKE : Emulate rfdi instruction

[Bharat Bhushan]

This patch adds "rfdi" instruction emulation which is required for
guest debug hander on BOOKE-HV

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/include/asm/kvm_host.h |  1 +
 arch/powerpc/kvm/booke_emulate.c    | 17 +++++++++++++++++
 2 files changed, 18 insertions(+)

diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 855ba4d..372b977 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -149,6 +149,7 @@ enum kvm_exit_types {
 	EMULATED_TLBWE_EXITS,
 	EMULATED_RFI_EXITS,
 	EMULATED_RFCI_EXITS,
+	EMULATED_RFDI_EXITS,
 	DEC_EXITS,
 	EXT_INTR_EXITS,
 	HALT_WAKEUP,
diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
index 80c51a2..2a20194 100644
--- a/arch/powerpc/kvm/booke_emulate.c
+++ b/arch/powerpc/kvm/booke_emulate.c
@@ -25,6 +25,7 @@
 
 #define OP_19_XOP_RFI     50
 #define OP_19_XOP_RFCI    51
+#define OP_19_XOP_RFDI    39
 
 #define OP_31_XOP_MFMSR   83
 #define OP_31_XOP_WRTEE   131
@@ -37,6 +38,16 @@ static void kvmppc_emul_rfi(struct kvm_vcpu *vcpu)
 	kvmppc_set_msr(vcpu, vcpu->arch.shared->srr1);
 }
 
+static void kvmppc_emul_rfdi(struct kvm_vcpu *vcpu)
+{
+	vcpu->arch.pc = vcpu->arch.dsrr0;
+	/* Force MSR_DE when guest does not own debug facilities */
+	if (vcpu->guest_debug)
+		kvmppc_set_msr(vcpu, vcpu->arch.dsrr1 | MSR_DE);
+	else
+		kvmppc_set_msr(vcpu, vcpu->arch.dsrr1);
+}
+
 static void kvmppc_emul_rfci(struct kvm_vcpu *vcpu)
 {
 	vcpu->arch.pc = vcpu->arch.csrr0;
@@ -69,6 +80,12 @@ int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
 			*advance = 0;
 			break;
 
+		case OP_19_XOP_RFDI:
+			kvmppc_emul_rfdi(vcpu);
+			kvmppc_set_exit_type(vcpu, EMULATED_RFDI_EXITS);
+			*advance = 0;
+			break;
+
 		default:
 			emulated = EMULATE_FAIL;
 			break;
-- 
1.9.3

[PATCH 5/6] KVM: PPC: BOOKE: Allow guest to change MSR_DE

[Bharat Bhushan]

When userspace is debugging guest then MSR_DE is always set and
MSRP_DEP is set so that guest cannot change MSR_DE.
Guest debug resources are not yet emulated, So there seems no reason
we should stop guest controlling MSR_DE.
Also a followup patch will enable debug emulation and that requires
guest to control MSR_DE.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/kvm/e500mc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 690499d..bd0a2bd 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -194,7 +194,7 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu)
 #ifdef CONFIG_64BIT
 	vcpu->arch.shadow_epcr |= SPRN_EPCR_ICM;
 #endif
-	vcpu->arch.shadow_msrp = MSRP_UCLEP | MSRP_DEP | MSRP_PMMP;
+	vcpu->arch.shadow_msrp = MSRP_UCLEP | MSRP_PMMP;
 	vcpu->arch.eplc = EPC_EGS | (vcpu->kvm->arch.lpid << EPC_ELPID_SHIFT);
 	vcpu->arch.epsc = vcpu->arch.eplc;
 
-- 
1.9.3

[PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat Bhushan]

This patch emulates debug registers and debug exception
to support guest using debug resource. This enables running
gdb/kgdb etc in guest.

On BOOKE architecture we cannot share debug resources between QEMU and
guest because:
    When QEMU is using debug resources then debug exception must
    be always enabled. To achieve this we set MSR_DE and also set
    MSRP_DEP so guest cannot change MSR_DE.

    When emulating debug resource for guest we want guest
    to control MSR_DE (enable/disable debug interrupt on need).

    So above mentioned two configuration cannot be supported
    at the same time. So the result is that we cannot share
    debug resources between QEMU and Guest on BOOKE architecture.

In the current design QEMU gets priority over guest, this means that if
QEMU is using debug resources then guest cannot use them and if guest is
using debug resource then QEMU can overwrite them.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
Hi Alex,

I thought of having some print in register emulation if QEMU
is using debug resource, Also when QEMU overwrites guest written
values but that looks excessive. If I uses some variable which
get set when guest starts using debug registers and check in
debug set ioctl then that look ugly. Looking for suggestions

 arch/powerpc/include/asm/kvm_ppc.h |   3 +
 arch/powerpc/kvm/booke.c           |  27 +++++++
 arch/powerpc/kvm/booke_emulate.c   | 157 +++++++++++++++++++++++++++++++++++++
 3 files changed, 187 insertions(+)

diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index e2fd5a1..f3f7611 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -173,6 +173,9 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq, u32 *server,
 extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
 extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
 
+void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu);
+void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu);
+
 union kvmppc_one_reg {
 	u32	wval;
 	u64	dval;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index fadfe76..c2471ed 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -264,6 +264,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu *vcpu)
 	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
 }
 
+void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu)
+{
+	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG);
+}
+
+void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu)
+{
+	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
+}
+
 static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0, u32 srr1)
 {
 #ifdef CONFIG_KVM_BOOKE_HV
@@ -783,6 +793,23 @@ static int kvmppc_handle_debug(struct kvm_run *run, struct kvm_vcpu *vcpu)
 	struct debug_reg *dbg_reg = &(vcpu->arch.shadow_dbg_reg);
 	u32 dbsr = vcpu->arch.dbsr;
 
+	if (vcpu->guest_debug == 0) {
+		/* Debug resources belong to Guest */
+		if (dbsr && (vcpu->arch.shared->msr & MSR_DE))
+			kvmppc_core_queue_debug(vcpu);
+
+		/* Inject a program interrupt if trap debug is not allowed */
+		if ((dbsr & DBSR_TIE) && !(vcpu->arch.shared->msr & MSR_DE))
+			kvmppc_core_queue_program(vcpu, ESR_PTR);
+
+		return RESUME_GUEST;
+	}
+
+	/*
+	 * Prepare for userspace exit as debug resources
+	 * are owned by userspace.
+	 */
+	vcpu->arch.dbsr = 0;
 	run->debug.arch.status = 0;
 	run->debug.arch.address = vcpu->arch.pc;
 
diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
index 2a20194..3d143fe 100644
--- a/arch/powerpc/kvm/booke_emulate.c
+++ b/arch/powerpc/kvm/booke_emulate.c
@@ -139,6 +139,7 @@ int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
 int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
 {
 	int emulated = EMULATE_DONE;
+	bool debug_inst = false;
 
 	switch (sprn) {
 	case SPRN_DEAR:
@@ -153,14 +154,137 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
 	case SPRN_CSRR1:
 		vcpu->arch.csrr1 = spr_val;
 		break;
+	case SPRN_DSRR0:
+		vcpu->arch.dsrr0 = spr_val;
+		break;
+	case SPRN_DSRR1:
+		vcpu->arch.dsrr1 = spr_val;
+		break;
+	case SPRN_IAC1:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac1 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac1 = spr_val;
+		break;
+	case SPRN_IAC2:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac2 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac2 = spr_val;
+		break;
+#if CONFIG_PPC_ADV_DEBUG_IACS > 2
+	case SPRN_IAC3:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac3 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac3 = spr_val;
+		break;
+	case SPRN_IAC4:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac4 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac4 = spr_val;
+		break;
+#endif
+	case SPRN_DAC1:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.dac1 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dac1 = spr_val;
+		break;
+	case SPRN_DAC2:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.dac2 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dac2 = spr_val;
+		break;
 	case SPRN_DBCR0:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		spr_val &= (DBCR0_IDM | DBCR0_IC | DBCR0_BT | DBCR0_TIE |
+			DBCR0_IAC1 | DBCR0_IAC2 | DBCR0_IAC3 | DBCR0_IAC4  |
+			DBCR0_DAC1R | DBCR0_DAC1W | DBCR0_DAC2R | DBCR0_DAC2W);
+
 		vcpu->arch.dbg_reg.dbcr0 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dbcr0 = spr_val;
 		break;
 	case SPRN_DBCR1:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
 		vcpu->arch.dbg_reg.dbcr1 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dbcr1 = spr_val;
+		break;
+	case SPRN_DBCR2:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.dbcr2 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
 		break;
 	case SPRN_DBSR:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
 		vcpu->arch.dbsr &= ~spr_val;
+		if (vcpu->arch.dbsr == 0)
+			kvmppc_core_dequeue_debug(vcpu);
 		break;
 	case SPRN_TSR:
 		kvmppc_clr_tsr_bits(vcpu, spr_val);
@@ -273,6 +397,10 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
 		emulated = EMULATE_FAIL;
 	}
 
+	if (debug_inst) {
+		switch_booke_debug_regs(&vcpu->arch.shadow_dbg_reg);
+		current->thread.debug = vcpu->arch.shadow_dbg_reg;
+	}
 	return emulated;
 }
 
@@ -299,12 +427,41 @@ int kvmppc_booke_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val)
 	case SPRN_CSRR1:
 		*spr_val = vcpu->arch.csrr1;
 		break;
+	case SPRN_DSRR0:
+		*spr_val = vcpu->arch.dsrr0;
+		break;
+	case SPRN_DSRR1:
+		*spr_val = vcpu->arch.dsrr1;
+		break;
+	case SPRN_IAC1:
+		*spr_val = vcpu->arch.dbg_reg.iac1;
+		break;
+	case SPRN_IAC2:
+		*spr_val = vcpu->arch.dbg_reg.iac2;
+		break;
+#if CONFIG_PPC_ADV_DEBUG_IACS > 2
+	case SPRN_IAC3:
+		*spr_val = vcpu->arch.dbg_reg.iac3;
+		break;
+	case SPRN_IAC4:
+		*spr_val = vcpu->arch.dbg_reg.iac4;
+		break;
+#endif
+	case SPRN_DAC1:
+		*spr_val = vcpu->arch.dbg_reg.dac1;
+		break;
+	case SPRN_DAC2:
+		*spr_val = vcpu->arch.dbg_reg.dac2;
+		break;
 	case SPRN_DBCR0:
 		*spr_val = vcpu->arch.dbg_reg.dbcr0;
 		break;
 	case SPRN_DBCR1:
 		*spr_val = vcpu->arch.dbg_reg.dbcr1;
 		break;
+	case SPRN_DBCR2:
+		*spr_val = vcpu->arch.dbg_reg.dbcr2;
+		break;
 	case SPRN_DBSR:
 		*spr_val = vcpu->arch.dbsr;
 		break;
-- 
1.9.3

[PATCH 0/6] Guest debug emulation

[Bharat Bhushan]

This patchset adds debug register and interrupt emulation support
for guest, which enables running gdb/kgdb etc in guest.
This also have couple of bux fixes

Bharat Bhushan (6):
  KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register
  KVM: PPC: BOOKE: Force MSR_DE in rfci if guest is under debug
  KVM: PPC: BOOKE: allow debug interrupt at "debug level"
  KVM: PPC: BOOKE : Emulate rfdi instruction
  KVM: PPC: BOOKE: Allow guest to change MSR_DE
  KVM: PPC: BOOKE: Emulate debug registers and exception

 arch/powerpc/include/asm/kvm_host.h |   1 +
 arch/powerpc/include/asm/kvm_ppc.h  |   3 +
 arch/powerpc/kvm/booke.c            |  35 ++++++-
 arch/powerpc/kvm/booke_emulate.c    | 180 +++++++++++++++++++++++++++++++++++-
 arch/powerpc/kvm/e500mc.c           |   2 +-
 5 files changed, 216 insertions(+), 5 deletions(-)

-- 
1.9.3

[PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Bharat Bhushan]

This is not used and  even I do not remember why this was added
in first place.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/kvm/booke.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index ab62109..a5ee42c 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -1804,8 +1804,6 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
 	kvm_guest_protect_msr(vcpu, MSR_DE, true);
 	vcpu->guest_debug = dbg->control;
 	vcpu->arch.shadow_dbg_reg.dbcr0 = 0;
-	/* Set DBCR0_EDM in guest visible DBCR0 register. */
-	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
 
 	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
 		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC;
-- 
1.9.3

[PATCH 2/6] KVM: PPC: BOOKE: Force MSR_DE in rfci if guest is under debug

[Bharat Bhushan]

When userspace (QEMU) is using the debug resource to debug guest
then we want MSR_DE to be always set. This patch adds missing
MSR_DE setting in "rfci" instruction.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/kvm/booke_emulate.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
index 27a4b28..80c51a2 100644
--- a/arch/powerpc/kvm/booke_emulate.c
+++ b/arch/powerpc/kvm/booke_emulate.c
@@ -40,7 +40,11 @@ static void kvmppc_emul_rfi(struct kvm_vcpu *vcpu)
 static void kvmppc_emul_rfci(struct kvm_vcpu *vcpu)
 {
 	vcpu->arch.pc = vcpu->arch.csrr0;
-	kvmppc_set_msr(vcpu, vcpu->arch.csrr1);
+	/* Force MSR_DE when guest does not own debug facilities */
+	if (vcpu->guest_debug)
+		kvmppc_set_msr(vcpu, vcpu->arch.csrr1 | MSR_DE);
+	else
+		kvmppc_set_msr(vcpu, vcpu->arch.csrr1);
 }
 
 int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
-- 
1.9.3

[PATCH 3/6] KVM: PPC: BOOKE: allow debug interrupt at "debug level"

[Bharat Bhushan]

Debug interrupt can be either "critical level" or "debug level".
There are separate set of save/restore registers used for different level.
Example: DSRR0/DSRR1 are used for "debug level" and CSRR0/CSRR1
are used for critical level debug interrupt.

Using CPU_FTR_DEBUG_LVL_EXC to decide which interrupt level to be used.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/kvm/booke.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index a5ee42c..fadfe76 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -424,7 +424,11 @@ static int kvmppc_booke_irqprio_deliver(struct kvm_vcpu *vcpu,
 		allowed = vcpu->arch.shared->msr & MSR_DE;
 		allowed = allowed && !crit;
 		msr_mask = MSR_ME;
-		int_class = INT_CLASS_CRIT;
+		if (cpu_has_feature(CPU_FTR_DEBUG_LVL_EXC))
+			int_class = INT_CLASS_DBG;
+		else
+			int_class = INT_CLASS_CRIT;
+
 		break;
 	}
 
-- 
1.9.3

[PATCH 4/6] KVM: PPC: BOOKE : Emulate rfdi instruction

[Bharat Bhushan]

This patch adds "rfdi" instruction emulation which is required for
guest debug hander on BOOKE-HV

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/include/asm/kvm_host.h |  1 +
 arch/powerpc/kvm/booke_emulate.c    | 17 +++++++++++++++++
 2 files changed, 18 insertions(+)

diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 855ba4d..372b977 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -149,6 +149,7 @@ enum kvm_exit_types {
 	EMULATED_TLBWE_EXITS,
 	EMULATED_RFI_EXITS,
 	EMULATED_RFCI_EXITS,
+	EMULATED_RFDI_EXITS,
 	DEC_EXITS,
 	EXT_INTR_EXITS,
 	HALT_WAKEUP,
diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
index 80c51a2..2a20194 100644
--- a/arch/powerpc/kvm/booke_emulate.c
+++ b/arch/powerpc/kvm/booke_emulate.c
@@ -25,6 +25,7 @@
 
 #define OP_19_XOP_RFI     50
 #define OP_19_XOP_RFCI    51
+#define OP_19_XOP_RFDI    39
 
 #define OP_31_XOP_MFMSR   83
 #define OP_31_XOP_WRTEE   131
@@ -37,6 +38,16 @@ static void kvmppc_emul_rfi(struct kvm_vcpu *vcpu)
 	kvmppc_set_msr(vcpu, vcpu->arch.shared->srr1);
 }
 
+static void kvmppc_emul_rfdi(struct kvm_vcpu *vcpu)
+{
+	vcpu->arch.pc = vcpu->arch.dsrr0;
+	/* Force MSR_DE when guest does not own debug facilities */
+	if (vcpu->guest_debug)
+		kvmppc_set_msr(vcpu, vcpu->arch.dsrr1 | MSR_DE);
+	else
+		kvmppc_set_msr(vcpu, vcpu->arch.dsrr1);
+}
+
 static void kvmppc_emul_rfci(struct kvm_vcpu *vcpu)
 {
 	vcpu->arch.pc = vcpu->arch.csrr0;
@@ -69,6 +80,12 @@ int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
 			*advance = 0;
 			break;
 
+		case OP_19_XOP_RFDI:
+			kvmppc_emul_rfdi(vcpu);
+			kvmppc_set_exit_type(vcpu, EMULATED_RFDI_EXITS);
+			*advance = 0;
+			break;
+
 		default:
 			emulated = EMULATE_FAIL;
 			break;
-- 
1.9.3

[PATCH 5/6] KVM: PPC: BOOKE: Allow guest to change MSR_DE

[Bharat Bhushan]

When userspace is debugging guest then MSR_DE is always set and
MSRP_DEP is set so that guest cannot change MSR_DE.
Guest debug resources are not yet emulated, So there seems no reason
we should stop guest controlling MSR_DE.
Also a followup patch will enable debug emulation and that requires
guest to control MSR_DE.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/kvm/e500mc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 690499d..bd0a2bd 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -194,7 +194,7 @@ int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu)
 #ifdef CONFIG_64BIT
 	vcpu->arch.shadow_epcr |= SPRN_EPCR_ICM;
 #endif
-	vcpu->arch.shadow_msrp = MSRP_UCLEP | MSRP_DEP | MSRP_PMMP;
+	vcpu->arch.shadow_msrp = MSRP_UCLEP | MSRP_PMMP;
 	vcpu->arch.eplc = EPC_EGS | (vcpu->kvm->arch.lpid << EPC_ELPID_SHIFT);
 	vcpu->arch.epsc = vcpu->arch.eplc;
 
-- 
1.9.3

[PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat Bhushan]

This patch emulates debug registers and debug exception
to support guest using debug resource. This enables running
gdb/kgdb etc in guest.

On BOOKE architecture we cannot share debug resources between QEMU and
guest because:
    When QEMU is using debug resources then debug exception must
    be always enabled. To achieve this we set MSR_DE and also set
    MSRP_DEP so guest cannot change MSR_DE.

    When emulating debug resource for guest we want guest
    to control MSR_DE (enable/disable debug interrupt on need).

    So above mentioned two configuration cannot be supported
    at the same time. So the result is that we cannot share
    debug resources between QEMU and Guest on BOOKE architecture.

In the current design QEMU gets priority over guest, this means that if
QEMU is using debug resources then guest cannot use them and if guest is
using debug resource then QEMU can overwrite them.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
Hi Alex,

I thought of having some print in register emulation if QEMU
is using debug resource, Also when QEMU overwrites guest written
values but that looks excessive. If I uses some variable which
get set when guest starts using debug registers and check in
debug set ioctl then that look ugly. Looking for suggestions

 arch/powerpc/include/asm/kvm_ppc.h |   3 +
 arch/powerpc/kvm/booke.c           |  27 +++++++
 arch/powerpc/kvm/booke_emulate.c   | 157 +++++++++++++++++++++++++++++++++++++
 3 files changed, 187 insertions(+)

diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index e2fd5a1..f3f7611 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -173,6 +173,9 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq, u32 *server,
 extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
 extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
 
+void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu);
+void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu);
+
 union kvmppc_one_reg {
 	u32	wval;
 	u64	dval;
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index fadfe76..c2471ed 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -264,6 +264,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu *vcpu)
 	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
 }
 
+void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu)
+{
+	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG);
+}
+
+void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu)
+{
+	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
+}
+
 static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0, u32 srr1)
 {
 #ifdef CONFIG_KVM_BOOKE_HV
@@ -783,6 +793,23 @@ static int kvmppc_handle_debug(struct kvm_run *run, struct kvm_vcpu *vcpu)
 	struct debug_reg *dbg_reg = &(vcpu->arch.shadow_dbg_reg);
 	u32 dbsr = vcpu->arch.dbsr;
 
+	if (vcpu->guest_debug = 0) {
+		/* Debug resources belong to Guest */
+		if (dbsr && (vcpu->arch.shared->msr & MSR_DE))
+			kvmppc_core_queue_debug(vcpu);
+
+		/* Inject a program interrupt if trap debug is not allowed */
+		if ((dbsr & DBSR_TIE) && !(vcpu->arch.shared->msr & MSR_DE))
+			kvmppc_core_queue_program(vcpu, ESR_PTR);
+
+		return RESUME_GUEST;
+	}
+
+	/*
+	 * Prepare for userspace exit as debug resources
+	 * are owned by userspace.
+	 */
+	vcpu->arch.dbsr = 0;
 	run->debug.arch.status = 0;
 	run->debug.arch.address = vcpu->arch.pc;
 
diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
index 2a20194..3d143fe 100644
--- a/arch/powerpc/kvm/booke_emulate.c
+++ b/arch/powerpc/kvm/booke_emulate.c
@@ -139,6 +139,7 @@ int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
 int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
 {
 	int emulated = EMULATE_DONE;
+	bool debug_inst = false;
 
 	switch (sprn) {
 	case SPRN_DEAR:
@@ -153,14 +154,137 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
 	case SPRN_CSRR1:
 		vcpu->arch.csrr1 = spr_val;
 		break;
+	case SPRN_DSRR0:
+		vcpu->arch.dsrr0 = spr_val;
+		break;
+	case SPRN_DSRR1:
+		vcpu->arch.dsrr1 = spr_val;
+		break;
+	case SPRN_IAC1:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac1 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac1 = spr_val;
+		break;
+	case SPRN_IAC2:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac2 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac2 = spr_val;
+		break;
+#if CONFIG_PPC_ADV_DEBUG_IACS > 2
+	case SPRN_IAC3:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac3 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac3 = spr_val;
+		break;
+	case SPRN_IAC4:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac4 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac4 = spr_val;
+		break;
+#endif
+	case SPRN_DAC1:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.dac1 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dac1 = spr_val;
+		break;
+	case SPRN_DAC2:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.dac2 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dac2 = spr_val;
+		break;
 	case SPRN_DBCR0:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		spr_val &= (DBCR0_IDM | DBCR0_IC | DBCR0_BT | DBCR0_TIE |
+			DBCR0_IAC1 | DBCR0_IAC2 | DBCR0_IAC3 | DBCR0_IAC4  |
+			DBCR0_DAC1R | DBCR0_DAC1W | DBCR0_DAC2R | DBCR0_DAC2W);
+
 		vcpu->arch.dbg_reg.dbcr0 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dbcr0 = spr_val;
 		break;
 	case SPRN_DBCR1:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
 		vcpu->arch.dbg_reg.dbcr1 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dbcr1 = spr_val;
+		break;
+	case SPRN_DBCR2:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
+		debug_inst = true;
+		vcpu->arch.dbg_reg.dbcr2 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
 		break;
 	case SPRN_DBSR:
+		/*
+		 * If userspace is debugging guest then guest
+		 * can not access debug registers.
+		 */
+		if (vcpu->guest_debug)
+			break;
+
 		vcpu->arch.dbsr &= ~spr_val;
+		if (vcpu->arch.dbsr = 0)
+			kvmppc_core_dequeue_debug(vcpu);
 		break;
 	case SPRN_TSR:
 		kvmppc_clr_tsr_bits(vcpu, spr_val);
@@ -273,6 +397,10 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
 		emulated = EMULATE_FAIL;
 	}
 
+	if (debug_inst) {
+		switch_booke_debug_regs(&vcpu->arch.shadow_dbg_reg);
+		current->thread.debug = vcpu->arch.shadow_dbg_reg;
+	}
 	return emulated;
 }
 
@@ -299,12 +427,41 @@ int kvmppc_booke_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn, ulong *spr_val)
 	case SPRN_CSRR1:
 		*spr_val = vcpu->arch.csrr1;
 		break;
+	case SPRN_DSRR0:
+		*spr_val = vcpu->arch.dsrr0;
+		break;
+	case SPRN_DSRR1:
+		*spr_val = vcpu->arch.dsrr1;
+		break;
+	case SPRN_IAC1:
+		*spr_val = vcpu->arch.dbg_reg.iac1;
+		break;
+	case SPRN_IAC2:
+		*spr_val = vcpu->arch.dbg_reg.iac2;
+		break;
+#if CONFIG_PPC_ADV_DEBUG_IACS > 2
+	case SPRN_IAC3:
+		*spr_val = vcpu->arch.dbg_reg.iac3;
+		break;
+	case SPRN_IAC4:
+		*spr_val = vcpu->arch.dbg_reg.iac4;
+		break;
+#endif
+	case SPRN_DAC1:
+		*spr_val = vcpu->arch.dbg_reg.dac1;
+		break;
+	case SPRN_DAC2:
+		*spr_val = vcpu->arch.dbg_reg.dac2;
+		break;
 	case SPRN_DBCR0:
 		*spr_val = vcpu->arch.dbg_reg.dbcr0;
 		break;
 	case SPRN_DBCR1:
 		*spr_val = vcpu->arch.dbg_reg.dbcr1;
 		break;
+	case SPRN_DBCR2:
+		*spr_val = vcpu->arch.dbg_reg.dbcr2;
+		break;
 	case SPRN_DBSR:
 		*spr_val = vcpu->arch.dbsr;
 		break;
-- 
1.9.3

Re: [PATCH 2/6] KVM: PPC: BOOKE: Force MSR_DE in rfci if guest is under debug

[Alexander Graf]

On 11.07.14 10:38, Bharat Bhushan wrote:
> When userspace (QEMU) is using the debug resource to debug guest
> then we want MSR_DE to be always set. This patch adds missing
> MSR_DE setting in "rfci" instruction.
>
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>

Shouldn't this be in kvmppc_set_msr() instead then to catch all users?


Alex

Re: [PATCH 2/6] KVM: PPC: BOOKE: Force MSR_DE in rfci if guest is under debug

[Alexander Graf]

On 11.07.14 10:38, Bharat Bhushan wrote:
> When userspace (QEMU) is using the debug resource to debug guest
> then we want MSR_DE to be always set. This patch adds missing
> MSR_DE setting in "rfci" instruction.
>
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>

Shouldn't this be in kvmppc_set_msr() instead then to catch all users?


Alex

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Alexander Graf]

On 11.07.14 10:39, Bharat Bhushan wrote:
> This patch emulates debug registers and debug exception
> to support guest using debug resource. This enables running
> gdb/kgdb etc in guest.
>
> On BOOKE architecture we cannot share debug resources between QEMU and
> guest because:
>      When QEMU is using debug resources then debug exception must
>      be always enabled. To achieve this we set MSR_DE and also set
>      MSRP_DEP so guest cannot change MSR_DE.
>
>      When emulating debug resource for guest we want guest
>      to control MSR_DE (enable/disable debug interrupt on need).
>
>      So above mentioned two configuration cannot be supported
>      at the same time. So the result is that we cannot share
>      debug resources between QEMU and Guest on BOOKE architecture.
>
> In the current design QEMU gets priority over guest, this means that if
> QEMU is using debug resources then guest cannot use them and if guest is
> using debug resource then QEMU can overwrite them.
>
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> ---
> Hi Alex,
>
> I thought of having some print in register emulation if QEMU
> is using debug resource, Also when QEMU overwrites guest written
> values but that looks excessive. If I uses some variable which
> get set when guest starts using debug registers and check in
> debug set ioctl then that look ugly. Looking for suggestions

Whatever you do, have QEMU do the print, not the kernel.

>
>   arch/powerpc/include/asm/kvm_ppc.h |   3 +
>   arch/powerpc/kvm/booke.c           |  27 +++++++
>   arch/powerpc/kvm/booke_emulate.c   | 157 +++++++++++++++++++++++++++++++++++++
>   3 files changed, 187 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index e2fd5a1..f3f7611 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -173,6 +173,9 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq, u32 *server,
>   extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
>   extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
>   
> +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu);
> +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu);
> +
>   union kvmppc_one_reg {
>   	u32	wval;
>   	u64	dval;
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index fadfe76..c2471ed 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -264,6 +264,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu *vcpu)
>   	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
>   }
>   
> +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu)
> +{
> +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG);
> +}
> +
> +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu)
> +{
> +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
> +}
> +
>   static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0, u32 srr1)
>   {
>   #ifdef CONFIG_KVM_BOOKE_HV
> @@ -783,6 +793,23 @@ static int kvmppc_handle_debug(struct kvm_run *run, struct kvm_vcpu *vcpu)
>   	struct debug_reg *dbg_reg = &(vcpu->arch.shadow_dbg_reg);
>   	u32 dbsr = vcpu->arch.dbsr;
>   
> +	if (vcpu->guest_debug == 0) {
> +		/* Debug resources belong to Guest */
> +		if (dbsr && (vcpu->arch.shared->msr & MSR_DE))
> +			kvmppc_core_queue_debug(vcpu);
> +
> +		/* Inject a program interrupt if trap debug is not allowed */
> +		if ((dbsr & DBSR_TIE) && !(vcpu->arch.shared->msr & MSR_DE))
> +			kvmppc_core_queue_program(vcpu, ESR_PTR);

In that case we would've received a program interrupt and never entered 
this code path, no?


Alex

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Alexander Graf]

On 11.07.14 10:39, Bharat Bhushan wrote:
> This patch emulates debug registers and debug exception
> to support guest using debug resource. This enables running
> gdb/kgdb etc in guest.
>
> On BOOKE architecture we cannot share debug resources between QEMU and
> guest because:
>      When QEMU is using debug resources then debug exception must
>      be always enabled. To achieve this we set MSR_DE and also set
>      MSRP_DEP so guest cannot change MSR_DE.
>
>      When emulating debug resource for guest we want guest
>      to control MSR_DE (enable/disable debug interrupt on need).
>
>      So above mentioned two configuration cannot be supported
>      at the same time. So the result is that we cannot share
>      debug resources between QEMU and Guest on BOOKE architecture.
>
> In the current design QEMU gets priority over guest, this means that if
> QEMU is using debug resources then guest cannot use them and if guest is
> using debug resource then QEMU can overwrite them.
>
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> ---
> Hi Alex,
>
> I thought of having some print in register emulation if QEMU
> is using debug resource, Also when QEMU overwrites guest written
> values but that looks excessive. If I uses some variable which
> get set when guest starts using debug registers and check in
> debug set ioctl then that look ugly. Looking for suggestions

Whatever you do, have QEMU do the print, not the kernel.

>
>   arch/powerpc/include/asm/kvm_ppc.h |   3 +
>   arch/powerpc/kvm/booke.c           |  27 +++++++
>   arch/powerpc/kvm/booke_emulate.c   | 157 +++++++++++++++++++++++++++++++++++++
>   3 files changed, 187 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index e2fd5a1..f3f7611 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -173,6 +173,9 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq, u32 *server,
>   extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
>   extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
>   
> +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu);
> +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu);
> +
>   union kvmppc_one_reg {
>   	u32	wval;
>   	u64	dval;
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index fadfe76..c2471ed 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -264,6 +264,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu *vcpu)
>   	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
>   }
>   
> +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu)
> +{
> +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG);
> +}
> +
> +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu)
> +{
> +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
> +}
> +
>   static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0, u32 srr1)
>   {
>   #ifdef CONFIG_KVM_BOOKE_HV
> @@ -783,6 +793,23 @@ static int kvmppc_handle_debug(struct kvm_run *run, struct kvm_vcpu *vcpu)
>   	struct debug_reg *dbg_reg = &(vcpu->arch.shadow_dbg_reg);
>   	u32 dbsr = vcpu->arch.dbsr;
>   
> +	if (vcpu->guest_debug = 0) {
> +		/* Debug resources belong to Guest */
> +		if (dbsr && (vcpu->arch.shared->msr & MSR_DE))
> +			kvmppc_core_queue_debug(vcpu);
> +
> +		/* Inject a program interrupt if trap debug is not allowed */
> +		if ((dbsr & DBSR_TIE) && !(vcpu->arch.shared->msr & MSR_DE))
> +			kvmppc_core_queue_program(vcpu, ESR_PTR);

In that case we would've received a program interrupt and never entered 
this code path, no?


Alex

Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Scott Wood]

On Fri, 2014-07-11 at 14:08 +0530, Bharat Bhushan wrote:
> This is not used and  even I do not remember why this was added
> in first place.
> 
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> ---
>  arch/powerpc/kvm/booke.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index ab62109..a5ee42c 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -1804,8 +1804,6 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>  	kvm_guest_protect_msr(vcpu, MSR_DE, true);
>  	vcpu->guest_debug = dbg->control;
>  	vcpu->arch.shadow_dbg_reg.dbcr0 = 0;
> -	/* Set DBCR0_EDM in guest visible DBCR0 register. */
> -	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
>  
>  	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
>  		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC;

This was intended to let the guest know that the host owns the debug
resources, by analogy to what a JTAG debugger would do.

The Power ISA has this "Virtualized Implementation Note":

        It is the responsibility of the hypervisor to ensure that
        DBCR0[EDM] is consistent with usage of DEP.

-Scott

Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Scott Wood]

On Fri, 2014-07-11 at 14:08 +0530, Bharat Bhushan wrote:
> This is not used and  even I do not remember why this was added
> in first place.
> 
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> ---
>  arch/powerpc/kvm/booke.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index ab62109..a5ee42c 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -1804,8 +1804,6 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>  	kvm_guest_protect_msr(vcpu, MSR_DE, true);
>  	vcpu->guest_debug = dbg->control;
>  	vcpu->arch.shadow_dbg_reg.dbcr0 = 0;
> -	/* Set DBCR0_EDM in guest visible DBCR0 register. */
> -	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
>  
>  	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
>  		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC;

This was intended to let the guest know that the host owns the debug
resources, by analogy to what a JTAG debugger would do.

The Power ISA has this "Virtualized Implementation Note":

        It is the responsibility of the hypervisor to ensure that
        DBCR0[EDM] is consistent with usage of DEP.

-Scott

Re: [PATCH 2/6] KVM: PPC: BOOKE: Force MSR_DE in rfci if guest is under debug

[Scott Wood]

On Fri, 2014-07-11 at 14:08 +0530, Bharat Bhushan wrote:
> When userspace (QEMU) is using the debug resource to debug guest
> then we want MSR_DE to be always set. This patch adds missing
> MSR_DE setting in "rfci" instruction.
> 
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> ---
>  arch/powerpc/kvm/booke_emulate.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
> index 27a4b28..80c51a2 100644
> --- a/arch/powerpc/kvm/booke_emulate.c
> +++ b/arch/powerpc/kvm/booke_emulate.c
> @@ -40,7 +40,11 @@ static void kvmppc_emul_rfi(struct kvm_vcpu *vcpu)
>  static void kvmppc_emul_rfci(struct kvm_vcpu *vcpu)
>  {
>  	vcpu->arch.pc = vcpu->arch.csrr0;
> -	kvmppc_set_msr(vcpu, vcpu->arch.csrr1);
> +	/* Force MSR_DE when guest does not own debug facilities */
> +	if (vcpu->guest_debug)
> +		kvmppc_set_msr(vcpu, vcpu->arch.csrr1 | MSR_DE);
> +	else
> +		kvmppc_set_msr(vcpu, vcpu->arch.csrr1);
>  }
>  
>  int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,

It looks like this is already handled by kvmppc_vcpu_sync_debug(), which
is called by kvmppc_set_msr().

Plus, it should only be done for HV mode.

-Scott

Re: [PATCH 2/6] KVM: PPC: BOOKE: Force MSR_DE in rfci if guest is under debug

[Scott Wood]

On Fri, 2014-07-11 at 14:08 +0530, Bharat Bhushan wrote:
> When userspace (QEMU) is using the debug resource to debug guest
> then we want MSR_DE to be always set. This patch adds missing
> MSR_DE setting in "rfci" instruction.
> 
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> ---
>  arch/powerpc/kvm/booke_emulate.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
> index 27a4b28..80c51a2 100644
> --- a/arch/powerpc/kvm/booke_emulate.c
> +++ b/arch/powerpc/kvm/booke_emulate.c
> @@ -40,7 +40,11 @@ static void kvmppc_emul_rfi(struct kvm_vcpu *vcpu)
>  static void kvmppc_emul_rfci(struct kvm_vcpu *vcpu)
>  {
>  	vcpu->arch.pc = vcpu->arch.csrr0;
> -	kvmppc_set_msr(vcpu, vcpu->arch.csrr1);
> +	/* Force MSR_DE when guest does not own debug facilities */
> +	if (vcpu->guest_debug)
> +		kvmppc_set_msr(vcpu, vcpu->arch.csrr1 | MSR_DE);
> +	else
> +		kvmppc_set_msr(vcpu, vcpu->arch.csrr1);
>  }
>  
>  int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,

It looks like this is already handled by kvmppc_vcpu_sync_debug(), which
is called by kvmppc_set_msr().

Plus, it should only be done for HV mode.

-Scott

Re: [PATCH 5/6] KVM: PPC: BOOKE: Allow guest to change MSR_DE

[Scott Wood]

On Fri, 2014-07-11 at 14:09 +0530, Bharat Bhushan wrote:
> When userspace is debugging guest then MSR_DE is always set and
> MSRP_DEP is set so that guest cannot change MSR_DE.
> Guest debug resources are not yet emulated, So there seems no reason
> we should stop guest controlling MSR_DE.
> Also a followup patch will enable debug emulation and that requires
> guest to control MSR_DE.

Why does it matter whether we emulate debug resources?  We still don't
want the guest to be able to clear MSR[DE] and thus break host debug.

-Scott

Re: [PATCH 5/6] KVM: PPC: BOOKE: Allow guest to change MSR_DE

[Scott Wood]

On Fri, 2014-07-11 at 14:09 +0530, Bharat Bhushan wrote:
> When userspace is debugging guest then MSR_DE is always set and
> MSRP_DEP is set so that guest cannot change MSR_DE.
> Guest debug resources are not yet emulated, So there seems no reason
> we should stop guest controlling MSR_DE.
> Also a followup patch will enable debug emulation and that requires
> guest to control MSR_DE.

Why does it matter whether we emulate debug resources?  We still don't
want the guest to be able to clear MSR[DE] and thus break host debug.

-Scott

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Fri, 2014-07-11 at 14:09 +0530, Bharat Bhushan wrote:
> This patch emulates debug registers and debug exception
> to support guest using debug resource. This enables running
> gdb/kgdb etc in guest.
> 
> On BOOKE architecture we cannot share debug resources between QEMU and
> guest because:
>     When QEMU is using debug resources then debug exception must
>     be always enabled. To achieve this we set MSR_DE and also set
>     MSRP_DEP so guest cannot change MSR_DE.
>
>     When emulating debug resource for guest we want guest
>     to control MSR_DE (enable/disable debug interrupt on need).
> 
>     So above mentioned two configuration cannot be supported
>     at the same time. So the result is that we cannot share
>     debug resources between QEMU and Guest on BOOKE architecture.
> 
> In the current design QEMU gets priority over guest, this means that if
> QEMU is using debug resources then guest cannot use them and if guest is
> using debug resource then QEMU can overwrite them.
> 
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> ---
> Hi Alex,
> 
> I thought of having some print in register emulation if QEMU
> is using debug resource, Also when QEMU overwrites guest written
> values but that looks excessive. If I uses some variable which
> get set when guest starts using debug registers and check in
> debug set ioctl then that look ugly. Looking for suggestions
> 
>  arch/powerpc/include/asm/kvm_ppc.h |   3 +
>  arch/powerpc/kvm/booke.c           |  27 +++++++
>  arch/powerpc/kvm/booke_emulate.c   | 157 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 187 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index e2fd5a1..f3f7611 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -173,6 +173,9 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq, u32 *server,
>  extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
>  extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
>  
> +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu);
> +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu);
> +
>  union kvmppc_one_reg {
>  	u32	wval;
>  	u64	dval;
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index fadfe76..c2471ed 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -264,6 +264,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu *vcpu)
>  	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
>  }
>  
> +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu)
> +{
> +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG);
> +}
> +
> +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu)
> +{
> +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
> +}
> +
>  static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0, u32 srr1)
>  {
>  #ifdef CONFIG_KVM_BOOKE_HV
> @@ -783,6 +793,23 @@ static int kvmppc_handle_debug(struct kvm_run *run, struct kvm_vcpu *vcpu)
>  	struct debug_reg *dbg_reg = &(vcpu->arch.shadow_dbg_reg);
>  	u32 dbsr = vcpu->arch.dbsr;
>  
> +	if (vcpu->guest_debug == 0) {
> +		/* Debug resources belong to Guest */
> +		if (dbsr && (vcpu->arch.shared->msr & MSR_DE))
> +			kvmppc_core_queue_debug(vcpu);

Should also check for DBCR0[IDM].

> +
> +		/* Inject a program interrupt if trap debug is not allowed */
> +		if ((dbsr & DBSR_TIE) && !(vcpu->arch.shared->msr & MSR_DE))
> +			kvmppc_core_queue_program(vcpu, ESR_PTR);
> +
> +		return RESUME_GUEST;
> +	}
> +
> +	/*
> +	 * Prepare for userspace exit as debug resources
> +	 * are owned by userspace.
> +	 */
> +	vcpu->arch.dbsr = 0;
>  	run->debug.arch.status = 0;
>  	run->debug.arch.address = vcpu->arch.pc;

Why are you clearing vcpu->arch.dbsr?  Userspace might be interested in
the raw value, plus it's a change from the current API semantics.

Where is this run->debug.arch.<foo> stuff and KVM_EXIT_DEBUG documented?


> diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
> index 2a20194..3d143fe 100644
> --- a/arch/powerpc/kvm/booke_emulate.c
> +++ b/arch/powerpc/kvm/booke_emulate.c
> @@ -139,6 +139,7 @@ int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
>  int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
>  {
>  	int emulated = EMULATE_DONE;
> +	bool debug_inst = false;
>  
>  	switch (sprn) {
>  	case SPRN_DEAR:
> @@ -153,14 +154,137 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
>  	case SPRN_CSRR1:
>  		vcpu->arch.csrr1 = spr_val;
>  		break;
> +	case SPRN_DSRR0:
> +		vcpu->arch.dsrr0 = spr_val;
> +		break;
> +	case SPRN_DSRR1:
> +		vcpu->arch.dsrr1 = spr_val;
> +		break;
> +	case SPRN_IAC1:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac1 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac1 = spr_val;
> +		break;
> +	case SPRN_IAC2:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac2 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac2 = spr_val;
> +		break;
> +#if CONFIG_PPC_ADV_DEBUG_IACS > 2
> +	case SPRN_IAC3:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac3 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac3 = spr_val;
> +		break;
> +	case SPRN_IAC4:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac4 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac4 = spr_val;
> +		break;
> +#endif
> +	case SPRN_DAC1:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.dac1 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dac1 = spr_val;
> +		break;
> +	case SPRN_DAC2:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.dac2 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dac2 = spr_val;
> +		break;
>  	case SPRN_DBCR0:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		spr_val &= (DBCR0_IDM | DBCR0_IC | DBCR0_BT | DBCR0_TIE |
> +			DBCR0_IAC1 | DBCR0_IAC2 | DBCR0_IAC3 | DBCR0_IAC4  |
> +			DBCR0_DAC1R | DBCR0_DAC1W | DBCR0_DAC2R | DBCR0_DAC2W);
> +
>  		vcpu->arch.dbg_reg.dbcr0 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dbcr0 = spr_val;
>  		break;
>  	case SPRN_DBCR1:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
>  		vcpu->arch.dbg_reg.dbcr1 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dbcr1 = spr_val;
> +		break;
> +	case SPRN_DBCR2:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.dbcr2 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
>  		break;

In what circumstances can the architected and shadow registers differ?

>  	case SPRN_DBSR:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
>  		vcpu->arch.dbsr &= ~spr_val;
> +		if (vcpu->arch.dbsr == 0)
> +			kvmppc_core_dequeue_debug(vcpu);
>  		break;

Not all DBSR bits cause an exception, e.g. IDE and MRR.

>  	case SPRN_TSR:
>  		kvmppc_clr_tsr_bits(vcpu, spr_val);
> @@ -273,6 +397,10 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
>  		emulated = EMULATE_FAIL;
>  	}
>  
> +	if (debug_inst) {
> +		switch_booke_debug_regs(&vcpu->arch.shadow_dbg_reg);
> +		current->thread.debug = vcpu->arch.shadow_dbg_reg;
> +	}

Could you explain what's going on with regard to copying the registers
into current->thread.debug?  Why is it done after loading the registers
into the hardware (is there a race if we get preempted in the middle)?

-Scott
;

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Fri, 2014-07-11 at 14:09 +0530, Bharat Bhushan wrote:
> This patch emulates debug registers and debug exception
> to support guest using debug resource. This enables running
> gdb/kgdb etc in guest.
> 
> On BOOKE architecture we cannot share debug resources between QEMU and
> guest because:
>     When QEMU is using debug resources then debug exception must
>     be always enabled. To achieve this we set MSR_DE and also set
>     MSRP_DEP so guest cannot change MSR_DE.
>
>     When emulating debug resource for guest we want guest
>     to control MSR_DE (enable/disable debug interrupt on need).
> 
>     So above mentioned two configuration cannot be supported
>     at the same time. So the result is that we cannot share
>     debug resources between QEMU and Guest on BOOKE architecture.
> 
> In the current design QEMU gets priority over guest, this means that if
> QEMU is using debug resources then guest cannot use them and if guest is
> using debug resource then QEMU can overwrite them.
> 
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> ---
> Hi Alex,
> 
> I thought of having some print in register emulation if QEMU
> is using debug resource, Also when QEMU overwrites guest written
> values but that looks excessive. If I uses some variable which
> get set when guest starts using debug registers and check in
> debug set ioctl then that look ugly. Looking for suggestions
> 
>  arch/powerpc/include/asm/kvm_ppc.h |   3 +
>  arch/powerpc/kvm/booke.c           |  27 +++++++
>  arch/powerpc/kvm/booke_emulate.c   | 157 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 187 insertions(+)
> 
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> index e2fd5a1..f3f7611 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -173,6 +173,9 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq, u32 *server,
>  extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
>  extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
>  
> +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu);
> +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu);
> +
>  union kvmppc_one_reg {
>  	u32	wval;
>  	u64	dval;
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index fadfe76..c2471ed 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -264,6 +264,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu *vcpu)
>  	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
>  }
>  
> +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu)
> +{
> +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG);
> +}
> +
> +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu)
> +{
> +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
> +}
> +
>  static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0, u32 srr1)
>  {
>  #ifdef CONFIG_KVM_BOOKE_HV
> @@ -783,6 +793,23 @@ static int kvmppc_handle_debug(struct kvm_run *run, struct kvm_vcpu *vcpu)
>  	struct debug_reg *dbg_reg = &(vcpu->arch.shadow_dbg_reg);
>  	u32 dbsr = vcpu->arch.dbsr;
>  
> +	if (vcpu->guest_debug = 0) {
> +		/* Debug resources belong to Guest */
> +		if (dbsr && (vcpu->arch.shared->msr & MSR_DE))
> +			kvmppc_core_queue_debug(vcpu);

Should also check for DBCR0[IDM].

> +
> +		/* Inject a program interrupt if trap debug is not allowed */
> +		if ((dbsr & DBSR_TIE) && !(vcpu->arch.shared->msr & MSR_DE))
> +			kvmppc_core_queue_program(vcpu, ESR_PTR);
> +
> +		return RESUME_GUEST;
> +	}
> +
> +	/*
> +	 * Prepare for userspace exit as debug resources
> +	 * are owned by userspace.
> +	 */
> +	vcpu->arch.dbsr = 0;
>  	run->debug.arch.status = 0;
>  	run->debug.arch.address = vcpu->arch.pc;

Why are you clearing vcpu->arch.dbsr?  Userspace might be interested in
the raw value, plus it's a change from the current API semantics.

Where is this run->debug.arch.<foo> stuff and KVM_EXIT_DEBUG documented?


> diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
> index 2a20194..3d143fe 100644
> --- a/arch/powerpc/kvm/booke_emulate.c
> +++ b/arch/powerpc/kvm/booke_emulate.c
> @@ -139,6 +139,7 @@ int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
>  int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
>  {
>  	int emulated = EMULATE_DONE;
> +	bool debug_inst = false;
>  
>  	switch (sprn) {
>  	case SPRN_DEAR:
> @@ -153,14 +154,137 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
>  	case SPRN_CSRR1:
>  		vcpu->arch.csrr1 = spr_val;
>  		break;
> +	case SPRN_DSRR0:
> +		vcpu->arch.dsrr0 = spr_val;
> +		break;
> +	case SPRN_DSRR1:
> +		vcpu->arch.dsrr1 = spr_val;
> +		break;
> +	case SPRN_IAC1:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac1 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac1 = spr_val;
> +		break;
> +	case SPRN_IAC2:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac2 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac2 = spr_val;
> +		break;
> +#if CONFIG_PPC_ADV_DEBUG_IACS > 2
> +	case SPRN_IAC3:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac3 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac3 = spr_val;
> +		break;
> +	case SPRN_IAC4:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac4 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac4 = spr_val;
> +		break;
> +#endif
> +	case SPRN_DAC1:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.dac1 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dac1 = spr_val;
> +		break;
> +	case SPRN_DAC2:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.dac2 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dac2 = spr_val;
> +		break;
>  	case SPRN_DBCR0:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		spr_val &= (DBCR0_IDM | DBCR0_IC | DBCR0_BT | DBCR0_TIE |
> +			DBCR0_IAC1 | DBCR0_IAC2 | DBCR0_IAC3 | DBCR0_IAC4  |
> +			DBCR0_DAC1R | DBCR0_DAC1W | DBCR0_DAC2R | DBCR0_DAC2W);
> +
>  		vcpu->arch.dbg_reg.dbcr0 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dbcr0 = spr_val;
>  		break;
>  	case SPRN_DBCR1:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
>  		vcpu->arch.dbg_reg.dbcr1 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dbcr1 = spr_val;
> +		break;
> +	case SPRN_DBCR2:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.dbcr2 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
>  		break;

In what circumstances can the architected and shadow registers differ?

>  	case SPRN_DBSR:
> +		/*
> +		 * If userspace is debugging guest then guest
> +		 * can not access debug registers.
> +		 */
> +		if (vcpu->guest_debug)
> +			break;
> +
>  		vcpu->arch.dbsr &= ~spr_val;
> +		if (vcpu->arch.dbsr = 0)
> +			kvmppc_core_dequeue_debug(vcpu);
>  		break;

Not all DBSR bits cause an exception, e.g. IDE and MRR.

>  	case SPRN_TSR:
>  		kvmppc_clr_tsr_bits(vcpu, spr_val);
> @@ -273,6 +397,10 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong spr_val)
>  		emulated = EMULATE_FAIL;
>  	}
>  
> +	if (debug_inst) {
> +		switch_booke_debug_regs(&vcpu->arch.shadow_dbg_reg);
> +		current->thread.debug = vcpu->arch.shadow_dbg_reg;
> +	}

Could you explain what's going on with regard to copying the registers
into current->thread.debug?  Why is it done after loading the registers
into the hardware (is there a race if we get preempted in the middle)?

-Scott
;

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Mon, 2014-07-28 at 16:04 +0200, Alexander Graf wrote:
> On 11.07.14 10:39, Bharat Bhushan wrote:
> > This patch emulates debug registers and debug exception
> > to support guest using debug resource. This enables running
> > gdb/kgdb etc in guest.
> >
> > On BOOKE architecture we cannot share debug resources between QEMU and
> > guest because:
> >      When QEMU is using debug resources then debug exception must
> >      be always enabled. To achieve this we set MSR_DE and also set
> >      MSRP_DEP so guest cannot change MSR_DE.
> >
> >      When emulating debug resource for guest we want guest
> >      to control MSR_DE (enable/disable debug interrupt on need).
> >
> >      So above mentioned two configuration cannot be supported
> >      at the same time. So the result is that we cannot share
> >      debug resources between QEMU and Guest on BOOKE architecture.
> >
> > In the current design QEMU gets priority over guest, this means that if
> > QEMU is using debug resources then guest cannot use them and if guest is
> > using debug resource then QEMU can overwrite them.
> >
> > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > ---
> > Hi Alex,
> >
> > I thought of having some print in register emulation if QEMU
> > is using debug resource, Also when QEMU overwrites guest written
> > values but that looks excessive. If I uses some variable which
> > get set when guest starts using debug registers and check in
> > debug set ioctl then that look ugly. Looking for suggestions
> 
> Whatever you do, have QEMU do the print, not the kernel.

How would that be accomplished?  How would the kernel know to exit to
QEMU, and how would the exit reason be conveyed?

-Scott

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Mon, 2014-07-28 at 16:04 +0200, Alexander Graf wrote:
> On 11.07.14 10:39, Bharat Bhushan wrote:
> > This patch emulates debug registers and debug exception
> > to support guest using debug resource. This enables running
> > gdb/kgdb etc in guest.
> >
> > On BOOKE architecture we cannot share debug resources between QEMU and
> > guest because:
> >      When QEMU is using debug resources then debug exception must
> >      be always enabled. To achieve this we set MSR_DE and also set
> >      MSRP_DEP so guest cannot change MSR_DE.
> >
> >      When emulating debug resource for guest we want guest
> >      to control MSR_DE (enable/disable debug interrupt on need).
> >
> >      So above mentioned two configuration cannot be supported
> >      at the same time. So the result is that we cannot share
> >      debug resources between QEMU and Guest on BOOKE architecture.
> >
> > In the current design QEMU gets priority over guest, this means that if
> > QEMU is using debug resources then guest cannot use them and if guest is
> > using debug resource then QEMU can overwrite them.
> >
> > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > ---
> > Hi Alex,
> >
> > I thought of having some print in register emulation if QEMU
> > is using debug resource, Also when QEMU overwrites guest written
> > values but that looks excessive. If I uses some variable which
> > get set when guest starts using debug registers and check in
> > debug set ioctl then that look ugly. Looking for suggestions
> 
> Whatever you do, have QEMU do the print, not the kernel.

How would that be accomplished?  How would the kernel know to exit to
QEMU, and how would the exit reason be conveyed?

-Scott

Re: [PATCH 5/6] KVM: PPC: BOOKE: Allow guest to change MSR_DE

[Alexander Graf]

On 29.07.14 00:01, Scott Wood wrote:
> On Fri, 2014-07-11 at 14:09 +0530, Bharat Bhushan wrote:
>> When userspace is debugging guest then MSR_DE is always set and
>> MSRP_DEP is set so that guest cannot change MSR_DE.
>> Guest debug resources are not yet emulated, So there seems no reason
>> we should stop guest controlling MSR_DE.
>> Also a followup patch will enable debug emulation and that requires
>> guest to control MSR_DE.
> Why does it matter whether we emulate debug resources?  We still don't
> want the guest to be able to clear MSR[DE] and thus break host debug.

The patch description is misleading. This patch changes the default of 
DEP to "guest controlled" when it boots up. Once QEMU wants control over 
the debug registers, it gets switched to "QEMU controlled" (that code is 
already there).


Alex

Re: [PATCH 5/6] KVM: PPC: BOOKE: Allow guest to change MSR_DE

[Alexander Graf]

On 29.07.14 00:01, Scott Wood wrote:
> On Fri, 2014-07-11 at 14:09 +0530, Bharat Bhushan wrote:
>> When userspace is debugging guest then MSR_DE is always set and
>> MSRP_DEP is set so that guest cannot change MSR_DE.
>> Guest debug resources are not yet emulated, So there seems no reason
>> we should stop guest controlling MSR_DE.
>> Also a followup patch will enable debug emulation and that requires
>> guest to control MSR_DE.
> Why does it matter whether we emulate debug resources?  We still don't
> want the guest to be able to clear MSR[DE] and thus break host debug.

The patch description is misleading. This patch changes the default of 
DEP to "guest controlled" when it boots up. Once QEMU wants control over 
the debug registers, it gets switched to "QEMU controlled" (that code is 
already there).


Alex

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Alexander Graf]

On 29.07.14 00:33, Scott Wood wrote:
> On Mon, 2014-07-28 at 16:04 +0200, Alexander Graf wrote:
>> On 11.07.14 10:39, Bharat Bhushan wrote:
>>> This patch emulates debug registers and debug exception
>>> to support guest using debug resource. This enables running
>>> gdb/kgdb etc in guest.
>>>
>>> On BOOKE architecture we cannot share debug resources between QEMU and
>>> guest because:
>>>       When QEMU is using debug resources then debug exception must
>>>       be always enabled. To achieve this we set MSR_DE and also set
>>>       MSRP_DEP so guest cannot change MSR_DE.
>>>
>>>       When emulating debug resource for guest we want guest
>>>       to control MSR_DE (enable/disable debug interrupt on need).
>>>
>>>       So above mentioned two configuration cannot be supported
>>>       at the same time. So the result is that we cannot share
>>>       debug resources between QEMU and Guest on BOOKE architecture.
>>>
>>> In the current design QEMU gets priority over guest, this means that if
>>> QEMU is using debug resources then guest cannot use them and if guest is
>>> using debug resource then QEMU can overwrite them.
>>>
>>> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
>>> ---
>>> Hi Alex,
>>>
>>> I thought of having some print in register emulation if QEMU
>>> is using debug resource, Also when QEMU overwrites guest written
>>> values but that looks excessive. If I uses some variable which
>>> get set when guest starts using debug registers and check in
>>> debug set ioctl then that look ugly. Looking for suggestions
>> Whatever you do, have QEMU do the print, not the kernel.
> How would that be accomplished?  How would the kernel know to exit to
> QEMU, and how would the exit reason be conveyed?

QEMU is the one forcefully enabling debug and overwriting guest debug 
registers, so it also knows when it did overwrite valid ones.


Alex

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Alexander Graf]

On 29.07.14 00:33, Scott Wood wrote:
> On Mon, 2014-07-28 at 16:04 +0200, Alexander Graf wrote:
>> On 11.07.14 10:39, Bharat Bhushan wrote:
>>> This patch emulates debug registers and debug exception
>>> to support guest using debug resource. This enables running
>>> gdb/kgdb etc in guest.
>>>
>>> On BOOKE architecture we cannot share debug resources between QEMU and
>>> guest because:
>>>       When QEMU is using debug resources then debug exception must
>>>       be always enabled. To achieve this we set MSR_DE and also set
>>>       MSRP_DEP so guest cannot change MSR_DE.
>>>
>>>       When emulating debug resource for guest we want guest
>>>       to control MSR_DE (enable/disable debug interrupt on need).
>>>
>>>       So above mentioned two configuration cannot be supported
>>>       at the same time. So the result is that we cannot share
>>>       debug resources between QEMU and Guest on BOOKE architecture.
>>>
>>> In the current design QEMU gets priority over guest, this means that if
>>> QEMU is using debug resources then guest cannot use them and if guest is
>>> using debug resource then QEMU can overwrite them.
>>>
>>> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
>>> ---
>>> Hi Alex,
>>>
>>> I thought of having some print in register emulation if QEMU
>>> is using debug resource, Also when QEMU overwrites guest written
>>> values but that looks excessive. If I uses some variable which
>>> get set when guest starts using debug registers and check in
>>> debug set ioctl then that look ugly. Looking for suggestions
>> Whatever you do, have QEMU do the print, not the kernel.
> How would that be accomplished?  How would the kernel know to exit to
> QEMU, and how would the exit reason be conveyed?

QEMU is the one forcefully enabling debug and overwriting guest debug 
registers, so it also knows when it did overwrite valid ones.


Alex

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Tue, 2014-07-29 at 16:06 +0200, Alexander Graf wrote:
> On 29.07.14 00:33, Scott Wood wrote:
> > On Mon, 2014-07-28 at 16:04 +0200, Alexander Graf wrote:
> >> On 11.07.14 10:39, Bharat Bhushan wrote:
> >>> This patch emulates debug registers and debug exception
> >>> to support guest using debug resource. This enables running
> >>> gdb/kgdb etc in guest.
> >>>
> >>> On BOOKE architecture we cannot share debug resources between QEMU and
> >>> guest because:
> >>>       When QEMU is using debug resources then debug exception must
> >>>       be always enabled. To achieve this we set MSR_DE and also set
> >>>       MSRP_DEP so guest cannot change MSR_DE.
> >>>
> >>>       When emulating debug resource for guest we want guest
> >>>       to control MSR_DE (enable/disable debug interrupt on need).
> >>>
> >>>       So above mentioned two configuration cannot be supported
> >>>       at the same time. So the result is that we cannot share
> >>>       debug resources between QEMU and Guest on BOOKE architecture.
> >>>
> >>> In the current design QEMU gets priority over guest, this means that if
> >>> QEMU is using debug resources then guest cannot use them and if guest is
> >>> using debug resource then QEMU can overwrite them.
> >>>
> >>> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> >>> ---
> >>> Hi Alex,
> >>>
> >>> I thought of having some print in register emulation if QEMU
> >>> is using debug resource, Also when QEMU overwrites guest written
> >>> values but that looks excessive. If I uses some variable which
> >>> get set when guest starts using debug registers and check in
> >>> debug set ioctl then that look ugly. Looking for suggestions
> >> Whatever you do, have QEMU do the print, not the kernel.
> > How would that be accomplished?  How would the kernel know to exit to
> > QEMU, and how would the exit reason be conveyed?
> 
> QEMU is the one forcefully enabling debug and overwriting guest debug 
> registers, so it also knows when it did overwrite valid ones.

QEMU knows when it overwrites the guest values, but it doesn't know if,
after enabling host debug, the guest tries to write to the debug
registers and it gets nopped.  If we keep the EDM setting, then we can
at least say the situation is no worse than with a JTAG.

-Scott

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Tue, 2014-07-29 at 16:06 +0200, Alexander Graf wrote:
> On 29.07.14 00:33, Scott Wood wrote:
> > On Mon, 2014-07-28 at 16:04 +0200, Alexander Graf wrote:
> >> On 11.07.14 10:39, Bharat Bhushan wrote:
> >>> This patch emulates debug registers and debug exception
> >>> to support guest using debug resource. This enables running
> >>> gdb/kgdb etc in guest.
> >>>
> >>> On BOOKE architecture we cannot share debug resources between QEMU and
> >>> guest because:
> >>>       When QEMU is using debug resources then debug exception must
> >>>       be always enabled. To achieve this we set MSR_DE and also set
> >>>       MSRP_DEP so guest cannot change MSR_DE.
> >>>
> >>>       When emulating debug resource for guest we want guest
> >>>       to control MSR_DE (enable/disable debug interrupt on need).
> >>>
> >>>       So above mentioned two configuration cannot be supported
> >>>       at the same time. So the result is that we cannot share
> >>>       debug resources between QEMU and Guest on BOOKE architecture.
> >>>
> >>> In the current design QEMU gets priority over guest, this means that if
> >>> QEMU is using debug resources then guest cannot use them and if guest is
> >>> using debug resource then QEMU can overwrite them.
> >>>
> >>> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> >>> ---
> >>> Hi Alex,
> >>>
> >>> I thought of having some print in register emulation if QEMU
> >>> is using debug resource, Also when QEMU overwrites guest written
> >>> values but that looks excessive. If I uses some variable which
> >>> get set when guest starts using debug registers and check in
> >>> debug set ioctl then that look ugly. Looking for suggestions
> >> Whatever you do, have QEMU do the print, not the kernel.
> > How would that be accomplished?  How would the kernel know to exit to
> > QEMU, and how would the exit reason be conveyed?
> 
> QEMU is the one forcefully enabling debug and overwriting guest debug 
> registers, so it also knows when it did overwrite valid ones.

QEMU knows when it overwrites the guest values, but it doesn't know if,
after enabling host debug, the guest tries to write to the debug
registers and it gets nopped.  If we keep the EDM setting, then we can
at least say the situation is no worse than with a JTAG.

-Scott

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Alexander Graf]

> Am 29.07.2014 um 19:50 schrieb Scott Wood <scottwood@freescale.com>:
> 
>> On Tue, 2014-07-29 at 16:06 +0200, Alexander Graf wrote:
>>> On 29.07.14 00:33, Scott Wood wrote:
>>>> On Mon, 2014-07-28 at 16:04 +0200, Alexander Graf wrote:
>>>>> On 11.07.14 10:39, Bharat Bhushan wrote:
>>>>> This patch emulates debug registers and debug exception
>>>>> to support guest using debug resource. This enables running
>>>>> gdb/kgdb etc in guest.
>>>>> 
>>>>> On BOOKE architecture we cannot share debug resources between QEMU and
>>>>> guest because:
>>>>>      When QEMU is using debug resources then debug exception must
>>>>>      be always enabled. To achieve this we set MSR_DE and also set
>>>>>      MSRP_DEP so guest cannot change MSR_DE.
>>>>> 
>>>>>      When emulating debug resource for guest we want guest
>>>>>      to control MSR_DE (enable/disable debug interrupt on need).
>>>>> 
>>>>>      So above mentioned two configuration cannot be supported
>>>>>      at the same time. So the result is that we cannot share
>>>>>      debug resources between QEMU and Guest on BOOKE architecture.
>>>>> 
>>>>> In the current design QEMU gets priority over guest, this means that if
>>>>> QEMU is using debug resources then guest cannot use them and if guest is
>>>>> using debug resource then QEMU can overwrite them.
>>>>> 
>>>>> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
>>>>> ---
>>>>> Hi Alex,
>>>>> 
>>>>> I thought of having some print in register emulation if QEMU
>>>>> is using debug resource, Also when QEMU overwrites guest written
>>>>> values but that looks excessive. If I uses some variable which
>>>>> get set when guest starts using debug registers and check in
>>>>> debug set ioctl then that look ugly. Looking for suggestions
>>>> Whatever you do, have QEMU do the print, not the kernel.
>>> How would that be accomplished?  How would the kernel know to exit to
>>> QEMU, and how would the exit reason be conveyed?
>> 
>> QEMU is the one forcefully enabling debug and overwriting guest debug 
>> registers, so it also knows when it did overwrite valid ones.
> 
> QEMU knows when it overwrites the guest values, but it doesn't know if,
> after enabling host debug, the guest tries to write to the debug
> registers and it gets nopped.  If we keep the EDM setting, then we can
> at least say the situation is no worse than with a JTAG.

Yeah, I think that's perfectly reasonable. I don't think it'll be likely that a user starts debugging with qemu and then expects guest debugging to work.

The other way around is more likely and would warrant a warning to the user - if we care.

Alex

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Alexander Graf]

> Am 29.07.2014 um 19:50 schrieb Scott Wood <scottwood@freescale.com>:
> 
>> On Tue, 2014-07-29 at 16:06 +0200, Alexander Graf wrote:
>>> On 29.07.14 00:33, Scott Wood wrote:
>>>> On Mon, 2014-07-28 at 16:04 +0200, Alexander Graf wrote:
>>>>> On 11.07.14 10:39, Bharat Bhushan wrote:
>>>>> This patch emulates debug registers and debug exception
>>>>> to support guest using debug resource. This enables running
>>>>> gdb/kgdb etc in guest.
>>>>> 
>>>>> On BOOKE architecture we cannot share debug resources between QEMU and
>>>>> guest because:
>>>>>      When QEMU is using debug resources then debug exception must
>>>>>      be always enabled. To achieve this we set MSR_DE and also set
>>>>>      MSRP_DEP so guest cannot change MSR_DE.
>>>>> 
>>>>>      When emulating debug resource for guest we want guest
>>>>>      to control MSR_DE (enable/disable debug interrupt on need).
>>>>> 
>>>>>      So above mentioned two configuration cannot be supported
>>>>>      at the same time. So the result is that we cannot share
>>>>>      debug resources between QEMU and Guest on BOOKE architecture.
>>>>> 
>>>>> In the current design QEMU gets priority over guest, this means that if
>>>>> QEMU is using debug resources then guest cannot use them and if guest is
>>>>> using debug resource then QEMU can overwrite them.
>>>>> 
>>>>> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
>>>>> ---
>>>>> Hi Alex,
>>>>> 
>>>>> I thought of having some print in register emulation if QEMU
>>>>> is using debug resource, Also when QEMU overwrites guest written
>>>>> values but that looks excessive. If I uses some variable which
>>>>> get set when guest starts using debug registers and check in
>>>>> debug set ioctl then that look ugly. Looking for suggestions
>>>> Whatever you do, have QEMU do the print, not the kernel.
>>> How would that be accomplished?  How would the kernel know to exit to
>>> QEMU, and how would the exit reason be conveyed?
>> 
>> QEMU is the one forcefully enabling debug and overwriting guest debug 
>> registers, so it also knows when it did overwrite valid ones.
> 
> QEMU knows when it overwrites the guest values, but it doesn't know if,
> after enabling host debug, the guest tries to write to the debug
> registers and it gets nopped.  If we keep the EDM setting, then we can
> at least say the situation is no worse than with a JTAG.

Yeah, I think that's perfectly reasonable. I don't think it'll be likely that a user starts debugging with qemu and then expects guest debugging to work.

The other way around is more likely and would warrant a warning to the user - if we care.

Alex

RE: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Bharat.Bhushan]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 29, 2014 3:22 AM
> To: Bhushan Bharat-R65777
> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> B08248
> Subject: Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest
> visible register
> 
> On Fri, 2014-07-11 at 14:08 +0530, Bharat Bhushan wrote:
> > This is not used and  even I do not remember why this was added in
> > first place.
> >
> > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > ---
> >  arch/powerpc/kvm/booke.c | 2 --
> >  1 file changed, 2 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c index
> > ab62109..a5ee42c 100644
> > --- a/arch/powerpc/kvm/booke.c
> > +++ b/arch/powerpc/kvm/booke.c
> > @@ -1804,8 +1804,6 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
> *vcpu,
> >  	kvm_guest_protect_msr(vcpu, MSR_DE, true);
> >  	vcpu->guest_debug = dbg->control;
> >  	vcpu->arch.shadow_dbg_reg.dbcr0 = 0;
> > -	/* Set DBCR0_EDM in guest visible DBCR0 register. */
> > -	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
> >
> >  	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
> >  		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC;
> 
> This was intended to let the guest know that the host owns the debug resources,
> by analogy to what a JTAG debugger would do.
> 
> The Power ISA has this "Virtualized Implementation Note":
> 
>         It is the responsibility of the hypervisor to ensure that
>         DBCR0[EDM] is consistent with usage of DEP.

Ok, That means that if MSRP_DEP is set then set DBCR0_EDM  and if MSRP_DEP is clear then clear DBCR0_EDM, right?
We need to implement above mentioned this.

Thanks
-Bharat

> 
> -Scott
> 

RE: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Bharat.Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgSnVseSAyOSwgMjAxNCAzOjIyIEFNDQo+IFRvOiBCaHVzaGFu
IEJoYXJhdC1SNjU3NzcNCj4gQ2M6IGFncmFmQHN1c2UuZGU7IGt2bS1wcGNAdmdlci5rZXJuZWwu
b3JnOyBrdm1Admdlci5rZXJuZWwub3JnOyBZb2RlciBTdHVhcnQtDQo+IEIwODI0OA0KPiBTdWJq
ZWN0OiBSZTogW1BBVENIIDEvNl0gS1ZNOiBQUEM6IEJPT0tFOiBObyBuZWVkIHRvIHNldCBEQkNS
MF9FRE0gaW4gZ3Vlc3QNCj4gdmlzaWJsZSByZWdpc3Rlcg0KPiANCj4gT24gRnJpLCAyMDE0LTA3
LTExIGF0IDE0OjA4ICswNTMwLCBCaGFyYXQgQmh1c2hhbiB3cm90ZToNCj4gPiBUaGlzIGlzIG5v
dCB1c2VkIGFuZCAgZXZlbiBJIGRvIG5vdCByZW1lbWJlciB3aHkgdGhpcyB3YXMgYWRkZWQgaW4N
Cj4gPiBmaXJzdCBwbGFjZS4NCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IEJoYXJhdCBCaHVzaGFu
IDxCaGFyYXQuQmh1c2hhbkBmcmVlc2NhbGUuY29tPg0KPiA+IC0tLQ0KPiA+ICBhcmNoL3Bvd2Vy
cGMva3ZtL2Jvb2tlLmMgfCAyIC0tDQo+ID4gIDEgZmlsZSBjaGFuZ2VkLCAyIGRlbGV0aW9ucygt
KQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9rdm0vYm9va2UuYyBiL2FyY2gv
cG93ZXJwYy9rdm0vYm9va2UuYyBpbmRleA0KPiA+IGFiNjIxMDkuLmE1ZWU0MmMgMTAwNjQ0DQo+
ID4gLS0tIGEvYXJjaC9wb3dlcnBjL2t2bS9ib29rZS5jDQo+ID4gKysrIGIvYXJjaC9wb3dlcnBj
L2t2bS9ib29rZS5jDQo+ID4gQEAgLTE4MDQsOCArMTgwNCw2IEBAIGludCBrdm1fYXJjaF92Y3B1
X2lvY3RsX3NldF9ndWVzdF9kZWJ1ZyhzdHJ1Y3Qga3ZtX3ZjcHUNCj4gKnZjcHUsDQo+ID4gIAlr
dm1fZ3Vlc3RfcHJvdGVjdF9tc3IodmNwdSwgTVNSX0RFLCB0cnVlKTsNCj4gPiAgCXZjcHUtPmd1
ZXN0X2RlYnVnID0gZGJnLT5jb250cm9sOw0KPiA+ICAJdmNwdS0+YXJjaC5zaGFkb3dfZGJnX3Jl
Zy5kYmNyMCA9IDA7DQo+ID4gLQkvKiBTZXQgREJDUjBfRURNIGluIGd1ZXN0IHZpc2libGUgREJD
UjAgcmVnaXN0ZXIuICovDQo+ID4gLQl2Y3B1LT5hcmNoLmRiZ19yZWcuZGJjcjAgPSBEQkNSMF9F
RE07DQo+ID4NCj4gPiAgCWlmICh2Y3B1LT5ndWVzdF9kZWJ1ZyAmIEtWTV9HVUVTVERCR19TSU5H
TEVTVEVQKQ0KPiA+ICAJCXZjcHUtPmFyY2guc2hhZG93X2RiZ19yZWcuZGJjcjAgfD0gREJDUjBf
SURNIHwgREJDUjBfSUM7DQo+IA0KPiBUaGlzIHdhcyBpbnRlbmRlZCB0byBsZXQgdGhlIGd1ZXN0
IGtub3cgdGhhdCB0aGUgaG9zdCBvd25zIHRoZSBkZWJ1ZyByZXNvdXJjZXMsDQo+IGJ5IGFuYWxv
Z3kgdG8gd2hhdCBhIEpUQUcgZGVidWdnZXIgd291bGQgZG8uDQo+IA0KPiBUaGUgUG93ZXIgSVNB
IGhhcyB0aGlzICJWaXJ0dWFsaXplZCBJbXBsZW1lbnRhdGlvbiBOb3RlIjoNCj4gDQo+ICAgICAg
ICAgSXQgaXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBoeXBlcnZpc29yIHRvIGVuc3VyZSB0
aGF0DQo+ICAgICAgICAgREJDUjBbRURNXSBpcyBjb25zaXN0ZW50IHdpdGggdXNhZ2Ugb2YgREVQ
Lg0KDQpPaywgVGhhdCBtZWFucyB0aGF0IGlmIE1TUlBfREVQIGlzIHNldCB0aGVuIHNldCBEQkNS
MF9FRE0gIGFuZCBpZiBNU1JQX0RFUCBpcyBjbGVhciB0aGVuIGNsZWFyIERCQ1IwX0VETSwgcmln
aHQ/DQpXZSBuZWVkIHRvIGltcGxlbWVudCBhYm92ZSBtZW50aW9uZWQgdGhpcy4NCg0KVGhhbmtz
DQotQmhhcmF0DQoNCj4gDQo+IC1TY290dA0KPiANCg0K

RE: [PATCH 2/6] KVM: PPC: BOOKE: Force MSR_DE in rfci if guest is under debug

[Bharat.Bhushan]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 29, 2014 3:25 AM
> To: Bhushan Bharat-R65777
> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> B08248
> Subject: Re: [PATCH 2/6] KVM: PPC: BOOKE: Force MSR_DE in rfci if guest is under
> debug
> 
> On Fri, 2014-07-11 at 14:08 +0530, Bharat Bhushan wrote:
> > When userspace (QEMU) is using the debug resource to debug guest then
> > we want MSR_DE to be always set. This patch adds missing MSR_DE
> > setting in "rfci" instruction.
> >
> > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > ---
> >  arch/powerpc/kvm/booke_emulate.c | 6 +++++-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kvm/booke_emulate.c
> > b/arch/powerpc/kvm/booke_emulate.c
> > index 27a4b28..80c51a2 100644
> > --- a/arch/powerpc/kvm/booke_emulate.c
> > +++ b/arch/powerpc/kvm/booke_emulate.c
> > @@ -40,7 +40,11 @@ static void kvmppc_emul_rfi(struct kvm_vcpu *vcpu)
> > static void kvmppc_emul_rfci(struct kvm_vcpu *vcpu)  {
> >  	vcpu->arch.pc = vcpu->arch.csrr0;
> > -	kvmppc_set_msr(vcpu, vcpu->arch.csrr1);
> > +	/* Force MSR_DE when guest does not own debug facilities */
> > +	if (vcpu->guest_debug)
> > +		kvmppc_set_msr(vcpu, vcpu->arch.csrr1 | MSR_DE);
> > +	else
> > +		kvmppc_set_msr(vcpu, vcpu->arch.csrr1);
> >  }
> >
> >  int kvmppc_booke_emulate_op(struct kvm_run *run, struct kvm_vcpu
> > *vcpu,
> 
> It looks like this is already handled by kvmppc_vcpu_sync_debug(), which is
> called by kvmppc_set_msr().

Yes, you are right. This patch is not needed.

Thanks
-Bharat

> 
> Plus, it should only be done for HV mode.
> 
> -Scott
> 

RE: [PATCH 2/6] KVM: PPC: BOOKE: Force MSR_DE in rfci if guest is under debug

[Bharat.Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgSnVseSAyOSwgMjAxNCAzOjI1IEFNDQo+IFRvOiBCaHVzaGFu
IEJoYXJhdC1SNjU3NzcNCj4gQ2M6IGFncmFmQHN1c2UuZGU7IGt2bS1wcGNAdmdlci5rZXJuZWwu
b3JnOyBrdm1Admdlci5rZXJuZWwub3JnOyBZb2RlciBTdHVhcnQtDQo+IEIwODI0OA0KPiBTdWJq
ZWN0OiBSZTogW1BBVENIIDIvNl0gS1ZNOiBQUEM6IEJPT0tFOiBGb3JjZSBNU1JfREUgaW4gcmZj
aSBpZiBndWVzdCBpcyB1bmRlcg0KPiBkZWJ1Zw0KPiANCj4gT24gRnJpLCAyMDE0LTA3LTExIGF0
IDE0OjA4ICswNTMwLCBCaGFyYXQgQmh1c2hhbiB3cm90ZToNCj4gPiBXaGVuIHVzZXJzcGFjZSAo
UUVNVSkgaXMgdXNpbmcgdGhlIGRlYnVnIHJlc291cmNlIHRvIGRlYnVnIGd1ZXN0IHRoZW4NCj4g
PiB3ZSB3YW50IE1TUl9ERSB0byBiZSBhbHdheXMgc2V0LiBUaGlzIHBhdGNoIGFkZHMgbWlzc2lu
ZyBNU1JfREUNCj4gPiBzZXR0aW5nIGluICJyZmNpIiBpbnN0cnVjdGlvbi4NCj4gPg0KPiA+IFNp
Z25lZC1vZmYtYnk6IEJoYXJhdCBCaHVzaGFuIDxCaGFyYXQuQmh1c2hhbkBmcmVlc2NhbGUuY29t
Pg0KPiA+IC0tLQ0KPiA+ICBhcmNoL3Bvd2VycGMva3ZtL2Jvb2tlX2VtdWxhdGUuYyB8IDYgKysr
KystDQo+ID4gIDEgZmlsZSBjaGFuZ2VkLCA1IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkN
Cj4gPg0KPiA+IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMva3ZtL2Jvb2tlX2VtdWxhdGUuYw0K
PiA+IGIvYXJjaC9wb3dlcnBjL2t2bS9ib29rZV9lbXVsYXRlLmMNCj4gPiBpbmRleCAyN2E0YjI4
Li44MGM1MWEyIDEwMDY0NA0KPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9rdm0vYm9va2VfZW11bGF0
ZS5jDQo+ID4gKysrIGIvYXJjaC9wb3dlcnBjL2t2bS9ib29rZV9lbXVsYXRlLmMNCj4gPiBAQCAt
NDAsNyArNDAsMTEgQEAgc3RhdGljIHZvaWQga3ZtcHBjX2VtdWxfcmZpKHN0cnVjdCBrdm1fdmNw
dSAqdmNwdSkNCj4gPiBzdGF0aWMgdm9pZCBrdm1wcGNfZW11bF9yZmNpKHN0cnVjdCBrdm1fdmNw
dSAqdmNwdSkgIHsNCj4gPiAgCXZjcHUtPmFyY2gucGMgPSB2Y3B1LT5hcmNoLmNzcnIwOw0KPiA+
IC0Ja3ZtcHBjX3NldF9tc3IodmNwdSwgdmNwdS0+YXJjaC5jc3JyMSk7DQo+ID4gKwkvKiBGb3Jj
ZSBNU1JfREUgd2hlbiBndWVzdCBkb2VzIG5vdCBvd24gZGVidWcgZmFjaWxpdGllcyAqLw0KPiA+
ICsJaWYgKHZjcHUtPmd1ZXN0X2RlYnVnKQ0KPiA+ICsJCWt2bXBwY19zZXRfbXNyKHZjcHUsIHZj
cHUtPmFyY2guY3NycjEgfCBNU1JfREUpOw0KPiA+ICsJZWxzZQ0KPiA+ICsJCWt2bXBwY19zZXRf
bXNyKHZjcHUsIHZjcHUtPmFyY2guY3NycjEpOw0KPiA+ICB9DQo+ID4NCj4gPiAgaW50IGt2bXBw
Y19ib29rZV9lbXVsYXRlX29wKHN0cnVjdCBrdm1fcnVuICpydW4sIHN0cnVjdCBrdm1fdmNwdQ0K
PiA+ICp2Y3B1LA0KPiANCj4gSXQgbG9va3MgbGlrZSB0aGlzIGlzIGFscmVhZHkgaGFuZGxlZCBi
eSBrdm1wcGNfdmNwdV9zeW5jX2RlYnVnKCksIHdoaWNoIGlzDQo+IGNhbGxlZCBieSBrdm1wcGNf
c2V0X21zcigpLg0KDQpZZXMsIHlvdSBhcmUgcmlnaHQuIFRoaXMgcGF0Y2ggaXMgbm90IG5lZWRl
ZC4NCg0KVGhhbmtzDQotQmhhcmF0DQoNCj4gDQo+IFBsdXMsIGl0IHNob3VsZCBvbmx5IGJlIGRv
bmUgZm9yIEhWIG1vZGUuDQo+IA0KPiAtU2NvdHQNCj4gDQoNCg=

RE: [PATCH 5/6] KVM: PPC: BOOKE: Allow guest to change MSR_DE

[Bharat.Bhushan]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Tuesday, July 29, 2014 7:35 PM
> To: Wood Scott-B07421; Bhushan Bharat-R65777
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-B08248
> Subject: Re: [PATCH 5/6] KVM: PPC: BOOKE: Allow guest to change MSR_DE
> 
> 
> On 29.07.14 00:01, Scott Wood wrote:
> > On Fri, 2014-07-11 at 14:09 +0530, Bharat Bhushan wrote:
> >> When userspace is debugging guest then MSR_DE is always set and
> >> MSRP_DEP is set so that guest cannot change MSR_DE.
> >> Guest debug resources are not yet emulated, So there seems no reason
> >> we should stop guest controlling MSR_DE.
> >> Also a followup patch will enable debug emulation and that requires
> >> guest to control MSR_DE.
> > Why does it matter whether we emulate debug resources?  We still don't
> > want the guest to be able to clear MSR[DE] and thus break host debug.
> 
> The patch description is misleading. This patch changes the default of DEP to
> "guest controlled" when it boots up. Once QEMU wants control over the debug
> registers, it gets switched to "QEMU controlled" (that code is already there).

Yes, now default MSR_DE is controlled by guest and when QEMU wants to use debug resources then MSR_DEP is set, so guest cannot change MSR_DE.

Thanks
-Bharat 

> 
> 
> Alex

RE: [PATCH 5/6] KVM: PPC: BOOKE: Allow guest to change MSR_DE

[Bharat.Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWxleGFuZGVyIEdyYWYg
W21haWx0bzphZ3JhZkBzdXNlLmRlXQ0KPiBTZW50OiBUdWVzZGF5LCBKdWx5IDI5LCAyMDE0IDc6
MzUgUE0NCj4gVG86IFdvb2QgU2NvdHQtQjA3NDIxOyBCaHVzaGFuIEJoYXJhdC1SNjU3NzcNCj4g
Q2M6IGt2bS1wcGNAdmdlci5rZXJuZWwub3JnOyBrdm1Admdlci5rZXJuZWwub3JnOyBZb2RlciBT
dHVhcnQtQjA4MjQ4DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggNS82XSBLVk06IFBQQzogQk9PS0U6
IEFsbG93IGd1ZXN0IHRvIGNoYW5nZSBNU1JfREUNCj4gDQo+IA0KPiBPbiAyOS4wNy4xNCAwMDow
MSwgU2NvdHQgV29vZCB3cm90ZToNCj4gPiBPbiBGcmksIDIwMTQtMDctMTEgYXQgMTQ6MDkgKzA1
MzAsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+PiBXaGVuIHVzZXJzcGFjZSBpcyBkZWJ1Z2dp
bmcgZ3Vlc3QgdGhlbiBNU1JfREUgaXMgYWx3YXlzIHNldCBhbmQNCj4gPj4gTVNSUF9ERVAgaXMg
c2V0IHNvIHRoYXQgZ3Vlc3QgY2Fubm90IGNoYW5nZSBNU1JfREUuDQo+ID4+IEd1ZXN0IGRlYnVn
IHJlc291cmNlcyBhcmUgbm90IHlldCBlbXVsYXRlZCwgU28gdGhlcmUgc2VlbXMgbm8gcmVhc29u
DQo+ID4+IHdlIHNob3VsZCBzdG9wIGd1ZXN0IGNvbnRyb2xsaW5nIE1TUl9ERS4NCj4gPj4gQWxz
byBhIGZvbGxvd3VwIHBhdGNoIHdpbGwgZW5hYmxlIGRlYnVnIGVtdWxhdGlvbiBhbmQgdGhhdCBy
ZXF1aXJlcw0KPiA+PiBndWVzdCB0byBjb250cm9sIE1TUl9ERS4NCj4gPiBXaHkgZG9lcyBpdCBt
YXR0ZXIgd2hldGhlciB3ZSBlbXVsYXRlIGRlYnVnIHJlc291cmNlcz8gIFdlIHN0aWxsIGRvbid0
DQo+ID4gd2FudCB0aGUgZ3Vlc3QgdG8gYmUgYWJsZSB0byBjbGVhciBNU1JbREVdIGFuZCB0aHVz
IGJyZWFrIGhvc3QgZGVidWcuDQo+IA0KPiBUaGUgcGF0Y2ggZGVzY3JpcHRpb24gaXMgbWlzbGVh
ZGluZy4gVGhpcyBwYXRjaCBjaGFuZ2VzIHRoZSBkZWZhdWx0IG9mIERFUCB0bw0KPiAiZ3Vlc3Qg
Y29udHJvbGxlZCIgd2hlbiBpdCBib290cyB1cC4gT25jZSBRRU1VIHdhbnRzIGNvbnRyb2wgb3Zl
ciB0aGUgZGVidWcNCj4gcmVnaXN0ZXJzLCBpdCBnZXRzIHN3aXRjaGVkIHRvICJRRU1VIGNvbnRy
b2xsZWQiICh0aGF0IGNvZGUgaXMgYWxyZWFkeSB0aGVyZSkuDQoNClllcywgbm93IGRlZmF1bHQg
TVNSX0RFIGlzIGNvbnRyb2xsZWQgYnkgZ3Vlc3QgYW5kIHdoZW4gUUVNVSB3YW50cyB0byB1c2Ug
ZGVidWcgcmVzb3VyY2VzIHRoZW4gTVNSX0RFUCBpcyBzZXQsIHNvIGd1ZXN0IGNhbm5vdCBjaGFu
Z2UgTVNSX0RFLg0KDQpUaGFua3MNCi1CaGFyYXQgDQoNCj4gDQo+IA0KPiBBbGV4DQoNCg=

RE: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat.Bhushan]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 29, 2014 11:20 PM
> To: Alexander Graf
> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder
> Stuart-B08248
> Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
> 
> On Tue, 2014-07-29 at 16:06 +0200, Alexander Graf wrote:
> > On 29.07.14 00:33, Scott Wood wrote:
> > > On Mon, 2014-07-28 at 16:04 +0200, Alexander Graf wrote:
> > >> On 11.07.14 10:39, Bharat Bhushan wrote:
> > >>> This patch emulates debug registers and debug exception to support
> > >>> guest using debug resource. This enables running gdb/kgdb etc in
> > >>> guest.
> > >>>
> > >>> On BOOKE architecture we cannot share debug resources between QEMU
> > >>> and guest because:
> > >>>       When QEMU is using debug resources then debug exception must
> > >>>       be always enabled. To achieve this we set MSR_DE and also set
> > >>>       MSRP_DEP so guest cannot change MSR_DE.
> > >>>
> > >>>       When emulating debug resource for guest we want guest
> > >>>       to control MSR_DE (enable/disable debug interrupt on need).
> > >>>
> > >>>       So above mentioned two configuration cannot be supported
> > >>>       at the same time. So the result is that we cannot share
> > >>>       debug resources between QEMU and Guest on BOOKE architecture.
> > >>>
> > >>> In the current design QEMU gets priority over guest, this means
> > >>> that if QEMU is using debug resources then guest cannot use them
> > >>> and if guest is using debug resource then QEMU can overwrite them.
> > >>>
> > >>> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > >>> ---
> > >>> Hi Alex,
> > >>>
> > >>> I thought of having some print in register emulation if QEMU is
> > >>> using debug resource, Also when QEMU overwrites guest written
> > >>> values but that looks excessive. If I uses some variable which get
> > >>> set when guest starts using debug registers and check in debug set
> > >>> ioctl then that look ugly. Looking for suggestions
> > >> Whatever you do, have QEMU do the print, not the kernel.
> > > How would that be accomplished?  How would the kernel know to exit
> > > to QEMU, and how would the exit reason be conveyed?
> >
> > QEMU is the one forcefully enabling debug and overwriting guest debug
> > registers, so it also knows when it did overwrite valid ones.
> 
> QEMU knows when it overwrites the guest values, but it doesn't know if, after
> enabling host debug, the guest tries to write to the debug registers and it gets
> nopped.

Do we want that QEMU first get DBCR0 to know whether it is overwriting whenever set/clear debug register?

>  If we keep the EDM setting, then we can at least say the situation is
> no worse than with a JTAG.

Yes

Thanks
-Bharat

> 
> -Scott
> 

RE: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat.Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgSnVseSAyOSwgMjAxNCAxMToyMCBQTQ0KPiBUbzogQWxleGFu
ZGVyIEdyYWYNCj4gQ2M6IEJodXNoYW4gQmhhcmF0LVI2NTc3Nzsga3ZtLXBwY0B2Z2VyLmtlcm5l
bC5vcmc7IGt2bUB2Z2VyLmtlcm5lbC5vcmc7IFlvZGVyDQo+IFN0dWFydC1CMDgyNDgNCj4gU3Vi
amVjdDogUmU6IFtQQVRDSCA2LzZdIEtWTTogUFBDOiBCT09LRTogRW11bGF0ZSBkZWJ1ZyByZWdp
c3RlcnMgYW5kIGV4Y2VwdGlvbg0KPiANCj4gT24gVHVlLCAyMDE0LTA3LTI5IGF0IDE2OjA2ICsw
MjAwLCBBbGV4YW5kZXIgR3JhZiB3cm90ZToNCj4gPiBPbiAyOS4wNy4xNCAwMDozMywgU2NvdHQg
V29vZCB3cm90ZToNCj4gPiA+IE9uIE1vbiwgMjAxNC0wNy0yOCBhdCAxNjowNCArMDIwMCwgQWxl
eGFuZGVyIEdyYWYgd3JvdGU6DQo+ID4gPj4gT24gMTEuMDcuMTQgMTA6MzksIEJoYXJhdCBCaHVz
aGFuIHdyb3RlOg0KPiA+ID4+PiBUaGlzIHBhdGNoIGVtdWxhdGVzIGRlYnVnIHJlZ2lzdGVycyBh
bmQgZGVidWcgZXhjZXB0aW9uIHRvIHN1cHBvcnQNCj4gPiA+Pj4gZ3Vlc3QgdXNpbmcgZGVidWcg
cmVzb3VyY2UuIFRoaXMgZW5hYmxlcyBydW5uaW5nIGdkYi9rZ2RiIGV0YyBpbg0KPiA+ID4+PiBn
dWVzdC4NCj4gPiA+Pj4NCj4gPiA+Pj4gT24gQk9PS0UgYXJjaGl0ZWN0dXJlIHdlIGNhbm5vdCBz
aGFyZSBkZWJ1ZyByZXNvdXJjZXMgYmV0d2VlbiBRRU1VDQo+ID4gPj4+IGFuZCBndWVzdCBiZWNh
dXNlOg0KPiA+ID4+PiAgICAgICBXaGVuIFFFTVUgaXMgdXNpbmcgZGVidWcgcmVzb3VyY2VzIHRo
ZW4gZGVidWcgZXhjZXB0aW9uIG11c3QNCj4gPiA+Pj4gICAgICAgYmUgYWx3YXlzIGVuYWJsZWQu
IFRvIGFjaGlldmUgdGhpcyB3ZSBzZXQgTVNSX0RFIGFuZCBhbHNvIHNldA0KPiA+ID4+PiAgICAg
ICBNU1JQX0RFUCBzbyBndWVzdCBjYW5ub3QgY2hhbmdlIE1TUl9ERS4NCj4gPiA+Pj4NCj4gPiA+
Pj4gICAgICAgV2hlbiBlbXVsYXRpbmcgZGVidWcgcmVzb3VyY2UgZm9yIGd1ZXN0IHdlIHdhbnQg
Z3Vlc3QNCj4gPiA+Pj4gICAgICAgdG8gY29udHJvbCBNU1JfREUgKGVuYWJsZS9kaXNhYmxlIGRl
YnVnIGludGVycnVwdCBvbiBuZWVkKS4NCj4gPiA+Pj4NCj4gPiA+Pj4gICAgICAgU28gYWJvdmUg
bWVudGlvbmVkIHR3byBjb25maWd1cmF0aW9uIGNhbm5vdCBiZSBzdXBwb3J0ZWQNCj4gPiA+Pj4g
ICAgICAgYXQgdGhlIHNhbWUgdGltZS4gU28gdGhlIHJlc3VsdCBpcyB0aGF0IHdlIGNhbm5vdCBz
aGFyZQ0KPiA+ID4+PiAgICAgICBkZWJ1ZyByZXNvdXJjZXMgYmV0d2VlbiBRRU1VIGFuZCBHdWVz
dCBvbiBCT09LRSBhcmNoaXRlY3R1cmUuDQo+ID4gPj4+DQo+ID4gPj4+IEluIHRoZSBjdXJyZW50
IGRlc2lnbiBRRU1VIGdldHMgcHJpb3JpdHkgb3ZlciBndWVzdCwgdGhpcyBtZWFucw0KPiA+ID4+
PiB0aGF0IGlmIFFFTVUgaXMgdXNpbmcgZGVidWcgcmVzb3VyY2VzIHRoZW4gZ3Vlc3QgY2Fubm90
IHVzZSB0aGVtDQo+ID4gPj4+IGFuZCBpZiBndWVzdCBpcyB1c2luZyBkZWJ1ZyByZXNvdXJjZSB0
aGVuIFFFTVUgY2FuIG92ZXJ3cml0ZSB0aGVtLg0KPiA+ID4+Pg0KPiA+ID4+PiBTaWduZWQtb2Zm
LWJ5OiBCaGFyYXQgQmh1c2hhbiA8QmhhcmF0LkJodXNoYW5AZnJlZXNjYWxlLmNvbT4NCj4gPiA+
Pj4gLS0tDQo+ID4gPj4+IEhpIEFsZXgsDQo+ID4gPj4+DQo+ID4gPj4+IEkgdGhvdWdodCBvZiBo
YXZpbmcgc29tZSBwcmludCBpbiByZWdpc3RlciBlbXVsYXRpb24gaWYgUUVNVSBpcw0KPiA+ID4+
PiB1c2luZyBkZWJ1ZyByZXNvdXJjZSwgQWxzbyB3aGVuIFFFTVUgb3ZlcndyaXRlcyBndWVzdCB3
cml0dGVuDQo+ID4gPj4+IHZhbHVlcyBidXQgdGhhdCBsb29rcyBleGNlc3NpdmUuIElmIEkgdXNl
cyBzb21lIHZhcmlhYmxlIHdoaWNoIGdldA0KPiA+ID4+PiBzZXQgd2hlbiBndWVzdCBzdGFydHMg
dXNpbmcgZGVidWcgcmVnaXN0ZXJzIGFuZCBjaGVjayBpbiBkZWJ1ZyBzZXQNCj4gPiA+Pj4gaW9j
dGwgdGhlbiB0aGF0IGxvb2sgdWdseS4gTG9va2luZyBmb3Igc3VnZ2VzdGlvbnMNCj4gPiA+PiBX
aGF0ZXZlciB5b3UgZG8sIGhhdmUgUUVNVSBkbyB0aGUgcHJpbnQsIG5vdCB0aGUga2VybmVsLg0K
PiA+ID4gSG93IHdvdWxkIHRoYXQgYmUgYWNjb21wbGlzaGVkPyAgSG93IHdvdWxkIHRoZSBrZXJu
ZWwga25vdyB0byBleGl0DQo+ID4gPiB0byBRRU1VLCBhbmQgaG93IHdvdWxkIHRoZSBleGl0IHJl
YXNvbiBiZSBjb252ZXllZD8NCj4gPg0KPiA+IFFFTVUgaXMgdGhlIG9uZSBmb3JjZWZ1bGx5IGVu
YWJsaW5nIGRlYnVnIGFuZCBvdmVyd3JpdGluZyBndWVzdCBkZWJ1Zw0KPiA+IHJlZ2lzdGVycywg
c28gaXQgYWxzbyBrbm93cyB3aGVuIGl0IGRpZCBvdmVyd3JpdGUgdmFsaWQgb25lcy4NCj4gDQo+
IFFFTVUga25vd3Mgd2hlbiBpdCBvdmVyd3JpdGVzIHRoZSBndWVzdCB2YWx1ZXMsIGJ1dCBpdCBk
b2Vzbid0IGtub3cgaWYsIGFmdGVyDQo+IGVuYWJsaW5nIGhvc3QgZGVidWcsIHRoZSBndWVzdCB0
cmllcyB0byB3cml0ZSB0byB0aGUgZGVidWcgcmVnaXN0ZXJzIGFuZCBpdCBnZXRzDQo+IG5vcHBl
ZC4NCg0KRG8gd2Ugd2FudCB0aGF0IFFFTVUgZmlyc3QgZ2V0IERCQ1IwIHRvIGtub3cgd2hldGhl
ciBpdCBpcyBvdmVyd3JpdGluZyB3aGVuZXZlciBzZXQvY2xlYXIgZGVidWcgcmVnaXN0ZXI/DQoN
Cj4gIElmIHdlIGtlZXAgdGhlIEVETSBzZXR0aW5nLCB0aGVuIHdlIGNhbiBhdCBsZWFzdCBzYXkg
dGhlIHNpdHVhdGlvbiBpcw0KPiBubyB3b3JzZSB0aGFuIHdpdGggYSBKVEFHLg0KDQpZZXMNCg0K
VGhhbmtzDQotQmhhcmF0DQoNCj4gDQo+IC1TY290dA0KPiANCg0K

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Alexander Graf]

> Am 30.07.2014 um 07:43 schrieb "Bharat.Bhushan@freescale.com" <Bharat.Bhushan@freescale.com>:
> 
> 
> 
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Tuesday, July 29, 2014 11:20 PM
>> To: Alexander Graf
>> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder
>> Stuart-B08248
>> Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
>> 
>>> On Tue, 2014-07-29 at 16:06 +0200, Alexander Graf wrote:
>>>> On 29.07.14 00:33, Scott Wood wrote:
>>>>> On Mon, 2014-07-28 at 16:04 +0200, Alexander Graf wrote:
>>>>>> On 11.07.14 10:39, Bharat Bhushan wrote:
>>>>>> This patch emulates debug registers and debug exception to support
>>>>>> guest using debug resource. This enables running gdb/kgdb etc in
>>>>>> guest.
>>>>>> 
>>>>>> On BOOKE architecture we cannot share debug resources between QEMU
>>>>>> and guest because:
>>>>>>      When QEMU is using debug resources then debug exception must
>>>>>>      be always enabled. To achieve this we set MSR_DE and also set
>>>>>>      MSRP_DEP so guest cannot change MSR_DE.
>>>>>> 
>>>>>>      When emulating debug resource for guest we want guest
>>>>>>      to control MSR_DE (enable/disable debug interrupt on need).
>>>>>> 
>>>>>>      So above mentioned two configuration cannot be supported
>>>>>>      at the same time. So the result is that we cannot share
>>>>>>      debug resources between QEMU and Guest on BOOKE architecture.
>>>>>> 
>>>>>> In the current design QEMU gets priority over guest, this means
>>>>>> that if QEMU is using debug resources then guest cannot use them
>>>>>> and if guest is using debug resource then QEMU can overwrite them.
>>>>>> 
>>>>>> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
>>>>>> ---
>>>>>> Hi Alex,
>>>>>> 
>>>>>> I thought of having some print in register emulation if QEMU is
>>>>>> using debug resource, Also when QEMU overwrites guest written
>>>>>> values but that looks excessive. If I uses some variable which get
>>>>>> set when guest starts using debug registers and check in debug set
>>>>>> ioctl then that look ugly. Looking for suggestions
>>>>> Whatever you do, have QEMU do the print, not the kernel.
>>>> How would that be accomplished?  How would the kernel know to exit
>>>> to QEMU, and how would the exit reason be conveyed?
>>> 
>>> QEMU is the one forcefully enabling debug and overwriting guest debug
>>> registers, so it also knows when it did overwrite valid ones.
>> 
>> QEMU knows when it overwrites the guest values, but it doesn't know if, after
>> enabling host debug, the guest tries to write to the debug registers and it gets
>> nopped.
> 
> Do we want that QEMU first get DBCR0 to know whether it is overwriting whenever set/clear debug register?

If you want to implement a warning, yes. But that csn easily be a follow-up. Let's get something properly working upstream first.

Alex

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Alexander Graf]

> Am 30.07.2014 um 07:43 schrieb "Bharat.Bhushan@freescale.com" <Bharat.Bhushan@freescale.com>:
> 
> 
> 
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Tuesday, July 29, 2014 11:20 PM
>> To: Alexander Graf
>> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder
>> Stuart-B08248
>> Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
>> 
>>> On Tue, 2014-07-29 at 16:06 +0200, Alexander Graf wrote:
>>>> On 29.07.14 00:33, Scott Wood wrote:
>>>>> On Mon, 2014-07-28 at 16:04 +0200, Alexander Graf wrote:
>>>>>> On 11.07.14 10:39, Bharat Bhushan wrote:
>>>>>> This patch emulates debug registers and debug exception to support
>>>>>> guest using debug resource. This enables running gdb/kgdb etc in
>>>>>> guest.
>>>>>> 
>>>>>> On BOOKE architecture we cannot share debug resources between QEMU
>>>>>> and guest because:
>>>>>>      When QEMU is using debug resources then debug exception must
>>>>>>      be always enabled. To achieve this we set MSR_DE and also set
>>>>>>      MSRP_DEP so guest cannot change MSR_DE.
>>>>>> 
>>>>>>      When emulating debug resource for guest we want guest
>>>>>>      to control MSR_DE (enable/disable debug interrupt on need).
>>>>>> 
>>>>>>      So above mentioned two configuration cannot be supported
>>>>>>      at the same time. So the result is that we cannot share
>>>>>>      debug resources between QEMU and Guest on BOOKE architecture.
>>>>>> 
>>>>>> In the current design QEMU gets priority over guest, this means
>>>>>> that if QEMU is using debug resources then guest cannot use them
>>>>>> and if guest is using debug resource then QEMU can overwrite them.
>>>>>> 
>>>>>> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
>>>>>> ---
>>>>>> Hi Alex,
>>>>>> 
>>>>>> I thought of having some print in register emulation if QEMU is
>>>>>> using debug resource, Also when QEMU overwrites guest written
>>>>>> values but that looks excessive. If I uses some variable which get
>>>>>> set when guest starts using debug registers and check in debug set
>>>>>> ioctl then that look ugly. Looking for suggestions
>>>>> Whatever you do, have QEMU do the print, not the kernel.
>>>> How would that be accomplished?  How would the kernel know to exit
>>>> to QEMU, and how would the exit reason be conveyed?
>>> 
>>> QEMU is the one forcefully enabling debug and overwriting guest debug
>>> registers, so it also knows when it did overwrite valid ones.
>> 
>> QEMU knows when it overwrites the guest values, but it doesn't know if, after
>> enabling host debug, the guest tries to write to the debug registers and it gets
>> nopped.
> 
> Do we want that QEMU first get DBCR0 to know whether it is overwriting whenever set/clear debug register?

If you want to implement a warning, yes. But that csn easily be a follow-up. Let's get something properly working upstream first.

Alex

RE: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat.Bhushan]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 29, 2014 3:58 AM
> To: Bhushan Bharat-R65777
> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> B08248
> Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
> 
> On Fri, 2014-07-11 at 14:09 +0530, Bharat Bhushan wrote:
> > This patch emulates debug registers and debug exception
> > to support guest using debug resource. This enables running
> > gdb/kgdb etc in guest.
> >
> > On BOOKE architecture we cannot share debug resources between QEMU and
> > guest because:
> >     When QEMU is using debug resources then debug exception must
> >     be always enabled. To achieve this we set MSR_DE and also set
> >     MSRP_DEP so guest cannot change MSR_DE.
> >
> >     When emulating debug resource for guest we want guest
> >     to control MSR_DE (enable/disable debug interrupt on need).
> >
> >     So above mentioned two configuration cannot be supported
> >     at the same time. So the result is that we cannot share
> >     debug resources between QEMU and Guest on BOOKE architecture.
> >
> > In the current design QEMU gets priority over guest, this means that if
> > QEMU is using debug resources then guest cannot use them and if guest is
> > using debug resource then QEMU can overwrite them.
> >
> > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > ---
> > Hi Alex,
> >
> > I thought of having some print in register emulation if QEMU
> > is using debug resource, Also when QEMU overwrites guest written
> > values but that looks excessive. If I uses some variable which
> > get set when guest starts using debug registers and check in
> > debug set ioctl then that look ugly. Looking for suggestions
> >
> >  arch/powerpc/include/asm/kvm_ppc.h |   3 +
> >  arch/powerpc/kvm/booke.c           |  27 +++++++
> >  arch/powerpc/kvm/booke_emulate.c   | 157
> +++++++++++++++++++++++++++++++++++++
> >  3 files changed, 187 insertions(+)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> b/arch/powerpc/include/asm/kvm_ppc.h
> > index e2fd5a1..f3f7611 100644
> > --- a/arch/powerpc/include/asm/kvm_ppc.h
> > +++ b/arch/powerpc/include/asm/kvm_ppc.h
> > @@ -173,6 +173,9 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq,
> u32 *server,
> >  extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
> >  extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
> >
> > +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu);
> > +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu);
> > +
> >  union kvmppc_one_reg {
> >  	u32	wval;
> >  	u64	dval;
> > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > index fadfe76..c2471ed 100644
> > --- a/arch/powerpc/kvm/booke.c
> > +++ b/arch/powerpc/kvm/booke.c
> > @@ -264,6 +264,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu
> *vcpu)
> >  	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
> >  }
> >
> > +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu)
> > +{
> > +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG);
> > +}
> > +
> > +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu)
> > +{
> > +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
> > +}
> > +
> >  static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0, u32
> srr1)
> >  {
> >  #ifdef CONFIG_KVM_BOOKE_HV
> > @@ -783,6 +793,23 @@ static int kvmppc_handle_debug(struct kvm_run *run,
> struct kvm_vcpu *vcpu)
> >  	struct debug_reg *dbg_reg = &(vcpu->arch.shadow_dbg_reg);
> >  	u32 dbsr = vcpu->arch.dbsr;
> >
> > +	if (vcpu->guest_debug == 0) {
> > +		/* Debug resources belong to Guest */
> > +		if (dbsr && (vcpu->arch.shared->msr & MSR_DE))
> > +			kvmppc_core_queue_debug(vcpu);
> 
> Should also check for DBCR0[IDM].

Ok

> 
> > +
> > +		/* Inject a program interrupt if trap debug is not allowed */
> > +		if ((dbsr & DBSR_TIE) && !(vcpu->arch.shared->msr & MSR_DE))
> > +			kvmppc_core_queue_program(vcpu, ESR_PTR);
> > +
> > +		return RESUME_GUEST;
> > +	}
> > +
> > +	/*
> > +	 * Prepare for userspace exit as debug resources
> > +	 * are owned by userspace.
> > +	 */
> > +	vcpu->arch.dbsr = 0;
> >  	run->debug.arch.status = 0;
> >  	run->debug.arch.address = vcpu->arch.pc;
> 
> Why are you clearing vcpu->arch.dbsr?

It was discussed in some other email, as soon as we decide that the debug interrupt is handled by QEMU then we clear vcpu->arch->dbsr.
- QEMU cannot inject debug interrupt to guest (as this does not know guest ability to handle debug interrupt; MSR_DE), so will always clear DBSR.
- If QEMU has to always clear DBSR than in handling KVM_EXIT_DEBUG then this avoid doing in SET_SREGS

>  Userspace might be interested in
> the raw value,

With the current design, If userspace is interested then it will not get the DBSR. But why userspace will be interested?

> plus it's a change from the current API semantics.

Can you please let us know how ?

> 
> Where is this run->debug.arch.<foo> stuff and KVM_EXIT_DEBUG documented?

I do not see anything in Documentation/.  While there is some not in arch/powerpc/include/uapi/asm/kvm.h.
(Note: this is not something new exit type added by this patch).

> 
> 
> > diff --git a/arch/powerpc/kvm/booke_emulate.c
> b/arch/powerpc/kvm/booke_emulate.c
> > index 2a20194..3d143fe 100644
> > --- a/arch/powerpc/kvm/booke_emulate.c
> > +++ b/arch/powerpc/kvm/booke_emulate.c
> > @@ -139,6 +139,7 @@ int kvmppc_booke_emulate_op(struct kvm_run *run, struct
> kvm_vcpu *vcpu,
> >  int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn, ulong
> spr_val)
> >  {
> >  	int emulated = EMULATE_DONE;
> > +	bool debug_inst = false;
> >
> >  	switch (sprn) {
> >  	case SPRN_DEAR:
> > @@ -153,14 +154,137 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu,
> int sprn, ulong spr_val)
> >  	case SPRN_CSRR1:
> >  		vcpu->arch.csrr1 = spr_val;
> >  		break;
> > +	case SPRN_DSRR0:
> > +		vcpu->arch.dsrr0 = spr_val;
> > +		break;
> > +	case SPRN_DSRR1:
> > +		vcpu->arch.dsrr1 = spr_val;
> > +		break;
> > +	case SPRN_IAC1:
> > +		/*
> > +		 * If userspace is debugging guest then guest
> > +		 * can not access debug registers.
> > +		 */
> > +		if (vcpu->guest_debug)
> > +			break;
> > +
> > +		debug_inst = true;
> > +		vcpu->arch.dbg_reg.iac1 = spr_val;
> > +		vcpu->arch.shadow_dbg_reg.iac1 = spr_val;
> > +		break;
> > +	case SPRN_IAC2:
> > +		/*
> > +		 * If userspace is debugging guest then guest
> > +		 * can not access debug registers.
> > +		 */
> > +		if (vcpu->guest_debug)
> > +			break;
> > +
> > +		debug_inst = true;
> > +		vcpu->arch.dbg_reg.iac2 = spr_val;
> > +		vcpu->arch.shadow_dbg_reg.iac2 = spr_val;
> > +		break;
> > +#if CONFIG_PPC_ADV_DEBUG_IACS > 2
> > +	case SPRN_IAC3:
> > +		/*
> > +		 * If userspace is debugging guest then guest
> > +		 * can not access debug registers.
> > +		 */
> > +		if (vcpu->guest_debug)
> > +			break;
> > +
> > +		debug_inst = true;
> > +		vcpu->arch.dbg_reg.iac3 = spr_val;
> > +		vcpu->arch.shadow_dbg_reg.iac3 = spr_val;
> > +		break;
> > +	case SPRN_IAC4:
> > +		/*
> > +		 * If userspace is debugging guest then guest
> > +		 * can not access debug registers.
> > +		 */
> > +		if (vcpu->guest_debug)
> > +			break;
> > +
> > +		debug_inst = true;
> > +		vcpu->arch.dbg_reg.iac4 = spr_val;
> > +		vcpu->arch.shadow_dbg_reg.iac4 = spr_val;
> > +		break;
> > +#endif
> > +	case SPRN_DAC1:
> > +		/*
> > +		 * If userspace is debugging guest then guest
> > +		 * can not access debug registers.
> > +		 */
> > +		if (vcpu->guest_debug)
> > +			break;
> > +
> > +		debug_inst = true;
> > +		vcpu->arch.dbg_reg.dac1 = spr_val;
> > +		vcpu->arch.shadow_dbg_reg.dac1 = spr_val;
> > +		break;
> > +	case SPRN_DAC2:
> > +		/*
> > +		 * If userspace is debugging guest then guest
> > +		 * can not access debug registers.
> > +		 */
> > +		if (vcpu->guest_debug)
> > +			break;
> > +
> > +		debug_inst = true;
> > +		vcpu->arch.dbg_reg.dac2 = spr_val;
> > +		vcpu->arch.shadow_dbg_reg.dac2 = spr_val;
> > +		break;
> >  	case SPRN_DBCR0:
> > +		/*
> > +		 * If userspace is debugging guest then guest
> > +		 * can not access debug registers.
> > +		 */
> > +		if (vcpu->guest_debug)
> > +			break;
> > +
> > +		debug_inst = true;
> > +		spr_val &= (DBCR0_IDM | DBCR0_IC | DBCR0_BT | DBCR0_TIE |
> > +			DBCR0_IAC1 | DBCR0_IAC2 | DBCR0_IAC3 | DBCR0_IAC4  |
> > +			DBCR0_DAC1R | DBCR0_DAC1W | DBCR0_DAC2R | DBCR0_DAC2W);
> > +
> >  		vcpu->arch.dbg_reg.dbcr0 = spr_val;
> > +		vcpu->arch.shadow_dbg_reg.dbcr0 = spr_val;
> >  		break;
> >  	case SPRN_DBCR1:
> > +		/*
> > +		 * If userspace is debugging guest then guest
> > +		 * can not access debug registers.
> > +		 */
> > +		if (vcpu->guest_debug)
> > +			break;
> > +
> > +		debug_inst = true;
> >  		vcpu->arch.dbg_reg.dbcr1 = spr_val;
> > +		vcpu->arch.shadow_dbg_reg.dbcr1 = spr_val;
> > +		break;
> > +	case SPRN_DBCR2:
> > +		/*
> > +		 * If userspace is debugging guest then guest
> > +		 * can not access debug registers.
> > +		 */
> > +		if (vcpu->guest_debug)
> > +			break;
> > +
> > +		debug_inst = true;
> > +		vcpu->arch.dbg_reg.dbcr2 = spr_val;
> > +		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
> >  		break;
> 
> In what circumstances can the architected and shadow registers differ?

As of now they are same. But I think that if we want to implement other features like "Freeze Timer (FT)" then they can be different.

> 
> >  	case SPRN_DBSR:
> > +		/*
> > +		 * If userspace is debugging guest then guest
> > +		 * can not access debug registers.
> > +		 */
> > +		if (vcpu->guest_debug)
> > +			break;
> > +
> >  		vcpu->arch.dbsr &= ~spr_val;
> > +		if (vcpu->arch.dbsr == 0)
> > +			kvmppc_core_dequeue_debug(vcpu);
> >  		break;
> 
> Not all DBSR bits cause an exception, e.g. IDE and MRR.

I am not sure what we should in that case ?
As we are currently emulating a subset of debug events (IAC, DAC, IC, BT and TIE --- DBCR0 emulation) then we should expose status of those events in guest dbsr and rest should be cleared ?

> 
> >  	case SPRN_TSR:
> >  		kvmppc_clr_tsr_bits(vcpu, spr_val);
> > @@ -273,6 +397,10 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int
> sprn, ulong spr_val)
> >  		emulated = EMULATE_FAIL;
> >  	}
> >
> > +	if (debug_inst) {
> > +		switch_booke_debug_regs(&vcpu->arch.shadow_dbg_reg);
> > +		current->thread.debug = vcpu->arch.shadow_dbg_reg;
> > +	}
> 
> Could you explain what's going on with regard to copying the registers
> into current->thread.debug?  Why is it done after loading the registers
> into the hardware (is there a race if we get preempted in the middle)?

Yes, and this was something I was not clear when writing this code. Should we have preempt disable-enable around this.

Thanks
-Bharat

> 
> -Scott
> ;

RE: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat.Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgSnVseSAyOSwgMjAxNCAzOjU4IEFNDQo+IFRvOiBCaHVzaGFu
IEJoYXJhdC1SNjU3NzcNCj4gQ2M6IGFncmFmQHN1c2UuZGU7IGt2bS1wcGNAdmdlci5rZXJuZWwu
b3JnOyBrdm1Admdlci5rZXJuZWwub3JnOyBZb2RlciBTdHVhcnQtDQo+IEIwODI0OA0KPiBTdWJq
ZWN0OiBSZTogW1BBVENIIDYvNl0gS1ZNOiBQUEM6IEJPT0tFOiBFbXVsYXRlIGRlYnVnIHJlZ2lz
dGVycyBhbmQgZXhjZXB0aW9uDQo+IA0KPiBPbiBGcmksIDIwMTQtMDctMTEgYXQgMTQ6MDkgKzA1
MzAsIEJoYXJhdCBCaHVzaGFuIHdyb3RlOg0KPiA+IFRoaXMgcGF0Y2ggZW11bGF0ZXMgZGVidWcg
cmVnaXN0ZXJzIGFuZCBkZWJ1ZyBleGNlcHRpb24NCj4gPiB0byBzdXBwb3J0IGd1ZXN0IHVzaW5n
IGRlYnVnIHJlc291cmNlLiBUaGlzIGVuYWJsZXMgcnVubmluZw0KPiA+IGdkYi9rZ2RiIGV0YyBp
biBndWVzdC4NCj4gPg0KPiA+IE9uIEJPT0tFIGFyY2hpdGVjdHVyZSB3ZSBjYW5ub3Qgc2hhcmUg
ZGVidWcgcmVzb3VyY2VzIGJldHdlZW4gUUVNVSBhbmQNCj4gPiBndWVzdCBiZWNhdXNlOg0KPiA+
ICAgICBXaGVuIFFFTVUgaXMgdXNpbmcgZGVidWcgcmVzb3VyY2VzIHRoZW4gZGVidWcgZXhjZXB0
aW9uIG11c3QNCj4gPiAgICAgYmUgYWx3YXlzIGVuYWJsZWQuIFRvIGFjaGlldmUgdGhpcyB3ZSBz
ZXQgTVNSX0RFIGFuZCBhbHNvIHNldA0KPiA+ICAgICBNU1JQX0RFUCBzbyBndWVzdCBjYW5ub3Qg
Y2hhbmdlIE1TUl9ERS4NCj4gPg0KPiA+ICAgICBXaGVuIGVtdWxhdGluZyBkZWJ1ZyByZXNvdXJj
ZSBmb3IgZ3Vlc3Qgd2Ugd2FudCBndWVzdA0KPiA+ICAgICB0byBjb250cm9sIE1TUl9ERSAoZW5h
YmxlL2Rpc2FibGUgZGVidWcgaW50ZXJydXB0IG9uIG5lZWQpLg0KPiA+DQo+ID4gICAgIFNvIGFi
b3ZlIG1lbnRpb25lZCB0d28gY29uZmlndXJhdGlvbiBjYW5ub3QgYmUgc3VwcG9ydGVkDQo+ID4g
ICAgIGF0IHRoZSBzYW1lIHRpbWUuIFNvIHRoZSByZXN1bHQgaXMgdGhhdCB3ZSBjYW5ub3Qgc2hh
cmUNCj4gPiAgICAgZGVidWcgcmVzb3VyY2VzIGJldHdlZW4gUUVNVSBhbmQgR3Vlc3Qgb24gQk9P
S0UgYXJjaGl0ZWN0dXJlLg0KPiA+DQo+ID4gSW4gdGhlIGN1cnJlbnQgZGVzaWduIFFFTVUgZ2V0
cyBwcmlvcml0eSBvdmVyIGd1ZXN0LCB0aGlzIG1lYW5zIHRoYXQgaWYNCj4gPiBRRU1VIGlzIHVz
aW5nIGRlYnVnIHJlc291cmNlcyB0aGVuIGd1ZXN0IGNhbm5vdCB1c2UgdGhlbSBhbmQgaWYgZ3Vl
c3QgaXMNCj4gPiB1c2luZyBkZWJ1ZyByZXNvdXJjZSB0aGVuIFFFTVUgY2FuIG92ZXJ3cml0ZSB0
aGVtLg0KPiA+DQo+ID4gU2lnbmVkLW9mZi1ieTogQmhhcmF0IEJodXNoYW4gPEJoYXJhdC5CaHVz
aGFuQGZyZWVzY2FsZS5jb20+DQo+ID4gLS0tDQo+ID4gSGkgQWxleCwNCj4gPg0KPiA+IEkgdGhv
dWdodCBvZiBoYXZpbmcgc29tZSBwcmludCBpbiByZWdpc3RlciBlbXVsYXRpb24gaWYgUUVNVQ0K
PiA+IGlzIHVzaW5nIGRlYnVnIHJlc291cmNlLCBBbHNvIHdoZW4gUUVNVSBvdmVyd3JpdGVzIGd1
ZXN0IHdyaXR0ZW4NCj4gPiB2YWx1ZXMgYnV0IHRoYXQgbG9va3MgZXhjZXNzaXZlLiBJZiBJIHVz
ZXMgc29tZSB2YXJpYWJsZSB3aGljaA0KPiA+IGdldCBzZXQgd2hlbiBndWVzdCBzdGFydHMgdXNp
bmcgZGVidWcgcmVnaXN0ZXJzIGFuZCBjaGVjayBpbg0KPiA+IGRlYnVnIHNldCBpb2N0bCB0aGVu
IHRoYXQgbG9vayB1Z2x5LiBMb29raW5nIGZvciBzdWdnZXN0aW9ucw0KPiA+DQo+ID4gIGFyY2gv
cG93ZXJwYy9pbmNsdWRlL2FzbS9rdm1fcHBjLmggfCAgIDMgKw0KPiA+ICBhcmNoL3Bvd2VycGMv
a3ZtL2Jvb2tlLmMgICAgICAgICAgIHwgIDI3ICsrKysrKysNCj4gPiAgYXJjaC9wb3dlcnBjL2t2
bS9ib29rZV9lbXVsYXRlLmMgICB8IDE1Nw0KPiArKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrDQo+ID4gIDMgZmlsZXMgY2hhbmdlZCwgMTg3IGluc2VydGlvbnMoKykNCj4gPg0K
PiA+IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20va3ZtX3BwYy5oDQo+IGIv
YXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL2t2bV9wcGMuaA0KPiA+IGluZGV4IGUyZmQ1YTEuLmYz
Zjc2MTEgMTAwNjQ0DQo+ID4gLS0tIGEvYXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL2t2bV9wcGMu
aA0KPiA+ICsrKyBiL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9rdm1fcHBjLmgNCj4gPiBAQCAt
MTczLDYgKzE3Myw5IEBAIGV4dGVybiBpbnQga3ZtcHBjX3hpY3NfZ2V0X3hpdmUoc3RydWN0IGt2
bSAqa3ZtLCB1MzIgaXJxLA0KPiB1MzIgKnNlcnZlciwNCj4gPiAgZXh0ZXJuIGludCBrdm1wcGNf
eGljc19pbnRfb24oc3RydWN0IGt2bSAqa3ZtLCB1MzIgaXJxKTsNCj4gPiAgZXh0ZXJuIGludCBr
dm1wcGNfeGljc19pbnRfb2ZmKHN0cnVjdCBrdm0gKmt2bSwgdTMyIGlycSk7DQo+ID4NCj4gPiAr
dm9pZCBrdm1wcGNfY29yZV9kZXF1ZXVlX2RlYnVnKHN0cnVjdCBrdm1fdmNwdSAqdmNwdSk7DQo+
ID4gK3ZvaWQga3ZtcHBjX2NvcmVfcXVldWVfZGVidWcoc3RydWN0IGt2bV92Y3B1ICp2Y3B1KTsN
Cj4gPiArDQo+ID4gIHVuaW9uIGt2bXBwY19vbmVfcmVnIHsNCj4gPiAgCXUzMgl3dmFsOw0KPiA+
ICAJdTY0CWR2YWw7DQo+ID4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9rdm0vYm9va2UuYyBi
L2FyY2gvcG93ZXJwYy9rdm0vYm9va2UuYw0KPiA+IGluZGV4IGZhZGZlNzYuLmMyNDcxZWQgMTAw
NjQ0DQo+ID4gLS0tIGEvYXJjaC9wb3dlcnBjL2t2bS9ib29rZS5jDQo+ID4gKysrIGIvYXJjaC9w
b3dlcnBjL2t2bS9ib29rZS5jDQo+ID4gQEAgLTI2NCw2ICsyNjQsMTYgQEAgc3RhdGljIHZvaWQg
a3ZtcHBjX2NvcmVfZGVxdWV1ZV93YXRjaGRvZyhzdHJ1Y3Qga3ZtX3ZjcHUNCj4gKnZjcHUpDQo+
ID4gIAljbGVhcl9iaXQoQk9PS0VfSVJRUFJJT19XQVRDSERPRywgJnZjcHUtPmFyY2gucGVuZGlu
Z19leGNlcHRpb25zKTsNCj4gPiAgfQ0KPiA+DQo+ID4gK3ZvaWQga3ZtcHBjX2NvcmVfcXVldWVf
ZGVidWcoc3RydWN0IGt2bV92Y3B1ICp2Y3B1KQ0KPiA+ICt7DQo+ID4gKwlrdm1wcGNfYm9va2Vf
cXVldWVfaXJxcHJpbyh2Y3B1LCBCT09LRV9JUlFQUklPX0RFQlVHKTsNCj4gPiArfQ0KPiA+ICsN
Cj4gPiArdm9pZCBrdm1wcGNfY29yZV9kZXF1ZXVlX2RlYnVnKHN0cnVjdCBrdm1fdmNwdSAqdmNw
dSkNCj4gPiArew0KPiA+ICsJY2xlYXJfYml0KEJPT0tFX0lSUVBSSU9fREVCVUcsICZ2Y3B1LT5h
cmNoLnBlbmRpbmdfZXhjZXB0aW9ucyk7DQo+ID4gK30NCj4gPiArDQo+ID4gIHN0YXRpYyB2b2lk
IHNldF9ndWVzdF9zcnIoc3RydWN0IGt2bV92Y3B1ICp2Y3B1LCB1bnNpZ25lZCBsb25nIHNycjAs
IHUzMg0KPiBzcnIxKQ0KPiA+ICB7DQo+ID4gICNpZmRlZiBDT05GSUdfS1ZNX0JPT0tFX0hWDQo+
ID4gQEAgLTc4Myw2ICs3OTMsMjMgQEAgc3RhdGljIGludCBrdm1wcGNfaGFuZGxlX2RlYnVnKHN0
cnVjdCBrdm1fcnVuICpydW4sDQo+IHN0cnVjdCBrdm1fdmNwdSAqdmNwdSkNCj4gPiAgCXN0cnVj
dCBkZWJ1Z19yZWcgKmRiZ19yZWcgPSAmKHZjcHUtPmFyY2guc2hhZG93X2RiZ19yZWcpOw0KPiA+
ICAJdTMyIGRic3IgPSB2Y3B1LT5hcmNoLmRic3I7DQo+ID4NCj4gPiArCWlmICh2Y3B1LT5ndWVz
dF9kZWJ1ZyA9PSAwKSB7DQo+ID4gKwkJLyogRGVidWcgcmVzb3VyY2VzIGJlbG9uZyB0byBHdWVz
dCAqLw0KPiA+ICsJCWlmIChkYnNyICYmICh2Y3B1LT5hcmNoLnNoYXJlZC0+bXNyICYgTVNSX0RF
KSkNCj4gPiArCQkJa3ZtcHBjX2NvcmVfcXVldWVfZGVidWcodmNwdSk7DQo+IA0KPiBTaG91bGQg
YWxzbyBjaGVjayBmb3IgREJDUjBbSURNXS4NCg0KT2sNCg0KPiANCj4gPiArDQo+ID4gKwkJLyog
SW5qZWN0IGEgcHJvZ3JhbSBpbnRlcnJ1cHQgaWYgdHJhcCBkZWJ1ZyBpcyBub3QgYWxsb3dlZCAq
Lw0KPiA+ICsJCWlmICgoZGJzciAmIERCU1JfVElFKSAmJiAhKHZjcHUtPmFyY2guc2hhcmVkLT5t
c3IgJiBNU1JfREUpKQ0KPiA+ICsJCQlrdm1wcGNfY29yZV9xdWV1ZV9wcm9ncmFtKHZjcHUsIEVT
Ul9QVFIpOw0KPiA+ICsNCj4gPiArCQlyZXR1cm4gUkVTVU1FX0dVRVNUOw0KPiA+ICsJfQ0KPiA+
ICsNCj4gPiArCS8qDQo+ID4gKwkgKiBQcmVwYXJlIGZvciB1c2Vyc3BhY2UgZXhpdCBhcyBkZWJ1
ZyByZXNvdXJjZXMNCj4gPiArCSAqIGFyZSBvd25lZCBieSB1c2Vyc3BhY2UuDQo+ID4gKwkgKi8N
Cj4gPiArCXZjcHUtPmFyY2guZGJzciA9IDA7DQo+ID4gIAlydW4tPmRlYnVnLmFyY2guc3RhdHVz
ID0gMDsNCj4gPiAgCXJ1bi0+ZGVidWcuYXJjaC5hZGRyZXNzID0gdmNwdS0+YXJjaC5wYzsNCj4g
DQo+IFdoeSBhcmUgeW91IGNsZWFyaW5nIHZjcHUtPmFyY2guZGJzcj8NCg0KSXQgd2FzIGRpc2N1
c3NlZCBpbiBzb21lIG90aGVyIGVtYWlsLCBhcyBzb29uIGFzIHdlIGRlY2lkZSB0aGF0IHRoZSBk
ZWJ1ZyBpbnRlcnJ1cHQgaXMgaGFuZGxlZCBieSBRRU1VIHRoZW4gd2UgY2xlYXIgdmNwdS0+YXJj
aC0+ZGJzci4NCi0gUUVNVSBjYW5ub3QgaW5qZWN0IGRlYnVnIGludGVycnVwdCB0byBndWVzdCAo
YXMgdGhpcyBkb2VzIG5vdCBrbm93IGd1ZXN0IGFiaWxpdHkgdG8gaGFuZGxlIGRlYnVnIGludGVy
cnVwdDsgTVNSX0RFKSwgc28gd2lsbCBhbHdheXMgY2xlYXIgREJTUi4NCi0gSWYgUUVNVSBoYXMg
dG8gYWx3YXlzIGNsZWFyIERCU1IgdGhhbiBpbiBoYW5kbGluZyBLVk1fRVhJVF9ERUJVRyB0aGVu
IHRoaXMgYXZvaWQgZG9pbmcgaW4gU0VUX1NSRUdTDQoNCj4gIFVzZXJzcGFjZSBtaWdodCBiZSBp
bnRlcmVzdGVkIGluDQo+IHRoZSByYXcgdmFsdWUsDQoNCldpdGggdGhlIGN1cnJlbnQgZGVzaWdu
LCBJZiB1c2Vyc3BhY2UgaXMgaW50ZXJlc3RlZCB0aGVuIGl0IHdpbGwgbm90IGdldCB0aGUgREJT
Ui4gQnV0IHdoeSB1c2Vyc3BhY2Ugd2lsbCBiZSBpbnRlcmVzdGVkPw0KDQo+IHBsdXMgaXQncyBh
IGNoYW5nZSBmcm9tIHRoZSBjdXJyZW50IEFQSSBzZW1hbnRpY3MuDQoNCkNhbiB5b3UgcGxlYXNl
IGxldCB1cyBrbm93IGhvdyA/DQoNCj4gDQo+IFdoZXJlIGlzIHRoaXMgcnVuLT5kZWJ1Zy5hcmNo
Ljxmb28+IHN0dWZmIGFuZCBLVk1fRVhJVF9ERUJVRyBkb2N1bWVudGVkPw0KDQpJIGRvIG5vdCBz
ZWUgYW55dGhpbmcgaW4gRG9jdW1lbnRhdGlvbi8uICBXaGlsZSB0aGVyZSBpcyBzb21lIG5vdCBp
biBhcmNoL3Bvd2VycGMvaW5jbHVkZS91YXBpL2FzbS9rdm0uaC4NCihOb3RlOiB0aGlzIGlzIG5v
dCBzb21ldGhpbmcgbmV3IGV4aXQgdHlwZSBhZGRlZCBieSB0aGlzIHBhdGNoKS4NCg0KPiANCj4g
DQo+ID4gZGlmZiAtLWdpdCBhL2FyY2gvcG93ZXJwYy9rdm0vYm9va2VfZW11bGF0ZS5jDQo+IGIv
YXJjaC9wb3dlcnBjL2t2bS9ib29rZV9lbXVsYXRlLmMNCj4gPiBpbmRleCAyYTIwMTk0Li4zZDE0
M2ZlIDEwMDY0NA0KPiA+IC0tLSBhL2FyY2gvcG93ZXJwYy9rdm0vYm9va2VfZW11bGF0ZS5jDQo+
ID4gKysrIGIvYXJjaC9wb3dlcnBjL2t2bS9ib29rZV9lbXVsYXRlLmMNCj4gPiBAQCAtMTM5LDYg
KzEzOSw3IEBAIGludCBrdm1wcGNfYm9va2VfZW11bGF0ZV9vcChzdHJ1Y3Qga3ZtX3J1biAqcnVu
LCBzdHJ1Y3QNCj4ga3ZtX3ZjcHUgKnZjcHUsDQo+ID4gIGludCBrdm1wcGNfYm9va2VfZW11bGF0
ZV9tdHNwcihzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUsIGludCBzcHJuLCB1bG9uZw0KPiBzcHJfdmFs
KQ0KPiA+ICB7DQo+ID4gIAlpbnQgZW11bGF0ZWQgPSBFTVVMQVRFX0RPTkU7DQo+ID4gKwlib29s
IGRlYnVnX2luc3QgPSBmYWxzZTsNCj4gPg0KPiA+ICAJc3dpdGNoIChzcHJuKSB7DQo+ID4gIAlj
YXNlIFNQUk5fREVBUjoNCj4gPiBAQCAtMTUzLDE0ICsxNTQsMTM3IEBAIGludCBrdm1wcGNfYm9v
a2VfZW11bGF0ZV9tdHNwcihzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUsDQo+IGludCBzcHJuLCB1bG9u
ZyBzcHJfdmFsKQ0KPiA+ICAJY2FzZSBTUFJOX0NTUlIxOg0KPiA+ICAJCXZjcHUtPmFyY2guY3Ny
cjEgPSBzcHJfdmFsOw0KPiA+ICAJCWJyZWFrOw0KPiA+ICsJY2FzZSBTUFJOX0RTUlIwOg0KPiA+
ICsJCXZjcHUtPmFyY2guZHNycjAgPSBzcHJfdmFsOw0KPiA+ICsJCWJyZWFrOw0KPiA+ICsJY2Fz
ZSBTUFJOX0RTUlIxOg0KPiA+ICsJCXZjcHUtPmFyY2guZHNycjEgPSBzcHJfdmFsOw0KPiA+ICsJ
CWJyZWFrOw0KPiA+ICsJY2FzZSBTUFJOX0lBQzE6DQo+ID4gKwkJLyoNCj4gPiArCQkgKiBJZiB1
c2Vyc3BhY2UgaXMgZGVidWdnaW5nIGd1ZXN0IHRoZW4gZ3Vlc3QNCj4gPiArCQkgKiBjYW4gbm90
IGFjY2VzcyBkZWJ1ZyByZWdpc3RlcnMuDQo+ID4gKwkJICovDQo+ID4gKwkJaWYgKHZjcHUtPmd1
ZXN0X2RlYnVnKQ0KPiA+ICsJCQlicmVhazsNCj4gPiArDQo+ID4gKwkJZGVidWdfaW5zdCA9IHRy
dWU7DQo+ID4gKwkJdmNwdS0+YXJjaC5kYmdfcmVnLmlhYzEgPSBzcHJfdmFsOw0KPiA+ICsJCXZj
cHUtPmFyY2guc2hhZG93X2RiZ19yZWcuaWFjMSA9IHNwcl92YWw7DQo+ID4gKwkJYnJlYWs7DQo+
ID4gKwljYXNlIFNQUk5fSUFDMjoNCj4gPiArCQkvKg0KPiA+ICsJCSAqIElmIHVzZXJzcGFjZSBp
cyBkZWJ1Z2dpbmcgZ3Vlc3QgdGhlbiBndWVzdA0KPiA+ICsJCSAqIGNhbiBub3QgYWNjZXNzIGRl
YnVnIHJlZ2lzdGVycy4NCj4gPiArCQkgKi8NCj4gPiArCQlpZiAodmNwdS0+Z3Vlc3RfZGVidWcp
DQo+ID4gKwkJCWJyZWFrOw0KPiA+ICsNCj4gPiArCQlkZWJ1Z19pbnN0ID0gdHJ1ZTsNCj4gPiAr
CQl2Y3B1LT5hcmNoLmRiZ19yZWcuaWFjMiA9IHNwcl92YWw7DQo+ID4gKwkJdmNwdS0+YXJjaC5z
aGFkb3dfZGJnX3JlZy5pYWMyID0gc3ByX3ZhbDsNCj4gPiArCQlicmVhazsNCj4gPiArI2lmIENP
TkZJR19QUENfQURWX0RFQlVHX0lBQ1MgPiAyDQo+ID4gKwljYXNlIFNQUk5fSUFDMzoNCj4gPiAr
CQkvKg0KPiA+ICsJCSAqIElmIHVzZXJzcGFjZSBpcyBkZWJ1Z2dpbmcgZ3Vlc3QgdGhlbiBndWVz
dA0KPiA+ICsJCSAqIGNhbiBub3QgYWNjZXNzIGRlYnVnIHJlZ2lzdGVycy4NCj4gPiArCQkgKi8N
Cj4gPiArCQlpZiAodmNwdS0+Z3Vlc3RfZGVidWcpDQo+ID4gKwkJCWJyZWFrOw0KPiA+ICsNCj4g
PiArCQlkZWJ1Z19pbnN0ID0gdHJ1ZTsNCj4gPiArCQl2Y3B1LT5hcmNoLmRiZ19yZWcuaWFjMyA9
IHNwcl92YWw7DQo+ID4gKwkJdmNwdS0+YXJjaC5zaGFkb3dfZGJnX3JlZy5pYWMzID0gc3ByX3Zh
bDsNCj4gPiArCQlicmVhazsNCj4gPiArCWNhc2UgU1BSTl9JQUM0Og0KPiA+ICsJCS8qDQo+ID4g
KwkJICogSWYgdXNlcnNwYWNlIGlzIGRlYnVnZ2luZyBndWVzdCB0aGVuIGd1ZXN0DQo+ID4gKwkJ
ICogY2FuIG5vdCBhY2Nlc3MgZGVidWcgcmVnaXN0ZXJzLg0KPiA+ICsJCSAqLw0KPiA+ICsJCWlm
ICh2Y3B1LT5ndWVzdF9kZWJ1ZykNCj4gPiArCQkJYnJlYWs7DQo+ID4gKw0KPiA+ICsJCWRlYnVn
X2luc3QgPSB0cnVlOw0KPiA+ICsJCXZjcHUtPmFyY2guZGJnX3JlZy5pYWM0ID0gc3ByX3ZhbDsN
Cj4gPiArCQl2Y3B1LT5hcmNoLnNoYWRvd19kYmdfcmVnLmlhYzQgPSBzcHJfdmFsOw0KPiA+ICsJ
CWJyZWFrOw0KPiA+ICsjZW5kaWYNCj4gPiArCWNhc2UgU1BSTl9EQUMxOg0KPiA+ICsJCS8qDQo+
ID4gKwkJICogSWYgdXNlcnNwYWNlIGlzIGRlYnVnZ2luZyBndWVzdCB0aGVuIGd1ZXN0DQo+ID4g
KwkJICogY2FuIG5vdCBhY2Nlc3MgZGVidWcgcmVnaXN0ZXJzLg0KPiA+ICsJCSAqLw0KPiA+ICsJ
CWlmICh2Y3B1LT5ndWVzdF9kZWJ1ZykNCj4gPiArCQkJYnJlYWs7DQo+ID4gKw0KPiA+ICsJCWRl
YnVnX2luc3QgPSB0cnVlOw0KPiA+ICsJCXZjcHUtPmFyY2guZGJnX3JlZy5kYWMxID0gc3ByX3Zh
bDsNCj4gPiArCQl2Y3B1LT5hcmNoLnNoYWRvd19kYmdfcmVnLmRhYzEgPSBzcHJfdmFsOw0KPiA+
ICsJCWJyZWFrOw0KPiA+ICsJY2FzZSBTUFJOX0RBQzI6DQo+ID4gKwkJLyoNCj4gPiArCQkgKiBJ
ZiB1c2Vyc3BhY2UgaXMgZGVidWdnaW5nIGd1ZXN0IHRoZW4gZ3Vlc3QNCj4gPiArCQkgKiBjYW4g
bm90IGFjY2VzcyBkZWJ1ZyByZWdpc3RlcnMuDQo+ID4gKwkJICovDQo+ID4gKwkJaWYgKHZjcHUt
Pmd1ZXN0X2RlYnVnKQ0KPiA+ICsJCQlicmVhazsNCj4gPiArDQo+ID4gKwkJZGVidWdfaW5zdCA9
IHRydWU7DQo+ID4gKwkJdmNwdS0+YXJjaC5kYmdfcmVnLmRhYzIgPSBzcHJfdmFsOw0KPiA+ICsJ
CXZjcHUtPmFyY2guc2hhZG93X2RiZ19yZWcuZGFjMiA9IHNwcl92YWw7DQo+ID4gKwkJYnJlYWs7
DQo+ID4gIAljYXNlIFNQUk5fREJDUjA6DQo+ID4gKwkJLyoNCj4gPiArCQkgKiBJZiB1c2Vyc3Bh
Y2UgaXMgZGVidWdnaW5nIGd1ZXN0IHRoZW4gZ3Vlc3QNCj4gPiArCQkgKiBjYW4gbm90IGFjY2Vz
cyBkZWJ1ZyByZWdpc3RlcnMuDQo+ID4gKwkJICovDQo+ID4gKwkJaWYgKHZjcHUtPmd1ZXN0X2Rl
YnVnKQ0KPiA+ICsJCQlicmVhazsNCj4gPiArDQo+ID4gKwkJZGVidWdfaW5zdCA9IHRydWU7DQo+
ID4gKwkJc3ByX3ZhbCAmPSAoREJDUjBfSURNIHwgREJDUjBfSUMgfCBEQkNSMF9CVCB8IERCQ1Iw
X1RJRSB8DQo+ID4gKwkJCURCQ1IwX0lBQzEgfCBEQkNSMF9JQUMyIHwgREJDUjBfSUFDMyB8IERC
Q1IwX0lBQzQgIHwNCj4gPiArCQkJREJDUjBfREFDMVIgfCBEQkNSMF9EQUMxVyB8IERCQ1IwX0RB
QzJSIHwgREJDUjBfREFDMlcpOw0KPiA+ICsNCj4gPiAgCQl2Y3B1LT5hcmNoLmRiZ19yZWcuZGJj
cjAgPSBzcHJfdmFsOw0KPiA+ICsJCXZjcHUtPmFyY2guc2hhZG93X2RiZ19yZWcuZGJjcjAgPSBz
cHJfdmFsOw0KPiA+ICAJCWJyZWFrOw0KPiA+ICAJY2FzZSBTUFJOX0RCQ1IxOg0KPiA+ICsJCS8q
DQo+ID4gKwkJICogSWYgdXNlcnNwYWNlIGlzIGRlYnVnZ2luZyBndWVzdCB0aGVuIGd1ZXN0DQo+
ID4gKwkJICogY2FuIG5vdCBhY2Nlc3MgZGVidWcgcmVnaXN0ZXJzLg0KPiA+ICsJCSAqLw0KPiA+
ICsJCWlmICh2Y3B1LT5ndWVzdF9kZWJ1ZykNCj4gPiArCQkJYnJlYWs7DQo+ID4gKw0KPiA+ICsJ
CWRlYnVnX2luc3QgPSB0cnVlOw0KPiA+ICAJCXZjcHUtPmFyY2guZGJnX3JlZy5kYmNyMSA9IHNw
cl92YWw7DQo+ID4gKwkJdmNwdS0+YXJjaC5zaGFkb3dfZGJnX3JlZy5kYmNyMSA9IHNwcl92YWw7
DQo+ID4gKwkJYnJlYWs7DQo+ID4gKwljYXNlIFNQUk5fREJDUjI6DQo+ID4gKwkJLyoNCj4gPiAr
CQkgKiBJZiB1c2Vyc3BhY2UgaXMgZGVidWdnaW5nIGd1ZXN0IHRoZW4gZ3Vlc3QNCj4gPiArCQkg
KiBjYW4gbm90IGFjY2VzcyBkZWJ1ZyByZWdpc3RlcnMuDQo+ID4gKwkJICovDQo+ID4gKwkJaWYg
KHZjcHUtPmd1ZXN0X2RlYnVnKQ0KPiA+ICsJCQlicmVhazsNCj4gPiArDQo+ID4gKwkJZGVidWdf
aW5zdCA9IHRydWU7DQo+ID4gKwkJdmNwdS0+YXJjaC5kYmdfcmVnLmRiY3IyID0gc3ByX3ZhbDsN
Cj4gPiArCQl2Y3B1LT5hcmNoLnNoYWRvd19kYmdfcmVnLmRiY3IyID0gc3ByX3ZhbDsNCj4gPiAg
CQlicmVhazsNCj4gDQo+IEluIHdoYXQgY2lyY3Vtc3RhbmNlcyBjYW4gdGhlIGFyY2hpdGVjdGVk
IGFuZCBzaGFkb3cgcmVnaXN0ZXJzIGRpZmZlcj8NCg0KQXMgb2Ygbm93IHRoZXkgYXJlIHNhbWUu
IEJ1dCBJIHRoaW5rIHRoYXQgaWYgd2Ugd2FudCB0byBpbXBsZW1lbnQgb3RoZXIgZmVhdHVyZXMg
bGlrZSAiRnJlZXplIFRpbWVyIChGVCkiIHRoZW4gdGhleSBjYW4gYmUgZGlmZmVyZW50Lg0KDQo+
IA0KPiA+ICAJY2FzZSBTUFJOX0RCU1I6DQo+ID4gKwkJLyoNCj4gPiArCQkgKiBJZiB1c2Vyc3Bh
Y2UgaXMgZGVidWdnaW5nIGd1ZXN0IHRoZW4gZ3Vlc3QNCj4gPiArCQkgKiBjYW4gbm90IGFjY2Vz
cyBkZWJ1ZyByZWdpc3RlcnMuDQo+ID4gKwkJICovDQo+ID4gKwkJaWYgKHZjcHUtPmd1ZXN0X2Rl
YnVnKQ0KPiA+ICsJCQlicmVhazsNCj4gPiArDQo+ID4gIAkJdmNwdS0+YXJjaC5kYnNyICY9IH5z
cHJfdmFsOw0KPiA+ICsJCWlmICh2Y3B1LT5hcmNoLmRic3IgPT0gMCkNCj4gPiArCQkJa3ZtcHBj
X2NvcmVfZGVxdWV1ZV9kZWJ1Zyh2Y3B1KTsNCj4gPiAgCQlicmVhazsNCj4gDQo+IE5vdCBhbGwg
REJTUiBiaXRzIGNhdXNlIGFuIGV4Y2VwdGlvbiwgZS5nLiBJREUgYW5kIE1SUi4NCg0KSSBhbSBu
b3Qgc3VyZSB3aGF0IHdlIHNob3VsZCBpbiB0aGF0IGNhc2UgPw0KQXMgd2UgYXJlIGN1cnJlbnRs
eSBlbXVsYXRpbmcgYSBzdWJzZXQgb2YgZGVidWcgZXZlbnRzIChJQUMsIERBQywgSUMsIEJUIGFu
ZCBUSUUgLS0tIERCQ1IwIGVtdWxhdGlvbikgdGhlbiB3ZSBzaG91bGQgZXhwb3NlIHN0YXR1cyBv
ZiB0aG9zZSBldmVudHMgaW4gZ3Vlc3QgZGJzciBhbmQgcmVzdCBzaG91bGQgYmUgY2xlYXJlZCA/
DQoNCj4gDQo+ID4gIAljYXNlIFNQUk5fVFNSOg0KPiA+ICAJCWt2bXBwY19jbHJfdHNyX2JpdHMo
dmNwdSwgc3ByX3ZhbCk7DQo+ID4gQEAgLTI3Myw2ICszOTcsMTAgQEAgaW50IGt2bXBwY19ib29r
ZV9lbXVsYXRlX210c3ByKHN0cnVjdCBrdm1fdmNwdSAqdmNwdSwgaW50DQo+IHNwcm4sIHVsb25n
IHNwcl92YWwpDQo+ID4gIAkJZW11bGF0ZWQgPSBFTVVMQVRFX0ZBSUw7DQo+ID4gIAl9DQo+ID4N
Cj4gPiArCWlmIChkZWJ1Z19pbnN0KSB7DQo+ID4gKwkJc3dpdGNoX2Jvb2tlX2RlYnVnX3JlZ3Mo
JnZjcHUtPmFyY2guc2hhZG93X2RiZ19yZWcpOw0KPiA+ICsJCWN1cnJlbnQtPnRocmVhZC5kZWJ1
ZyA9IHZjcHUtPmFyY2guc2hhZG93X2RiZ19yZWc7DQo+ID4gKwl9DQo+IA0KPiBDb3VsZCB5b3Ug
ZXhwbGFpbiB3aGF0J3MgZ29pbmcgb24gd2l0aCByZWdhcmQgdG8gY29weWluZyB0aGUgcmVnaXN0
ZXJzDQo+IGludG8gY3VycmVudC0+dGhyZWFkLmRlYnVnPyAgV2h5IGlzIGl0IGRvbmUgYWZ0ZXIg
bG9hZGluZyB0aGUgcmVnaXN0ZXJzDQo+IGludG8gdGhlIGhhcmR3YXJlIChpcyB0aGVyZSBhIHJh
Y2UgaWYgd2UgZ2V0IHByZWVtcHRlZCBpbiB0aGUgbWlkZGxlKT8NCg0KWWVzLCBhbmQgdGhpcyB3
YXMgc29tZXRoaW5nIEkgd2FzIG5vdCBjbGVhciB3aGVuIHdyaXRpbmcgdGhpcyBjb2RlLiBTaG91
bGQgd2UgaGF2ZSBwcmVlbXB0IGRpc2FibGUtZW5hYmxlIGFyb3VuZCB0aGlzLg0KDQpUaGFua3MN
Ci1CaGFyYXQNCg0KPiANCj4gLVNjb3R0DQo+IDsNCg0K

RE: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat.Bhushan]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Monday, July 28, 2014 7:35 PM
> To: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org
> Cc: kvm@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248
> Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
> 
> 
> On 11.07.14 10:39, Bharat Bhushan wrote:
> > This patch emulates debug registers and debug exception to support
> > guest using debug resource. This enables running gdb/kgdb etc in
> > guest.
> >
> > On BOOKE architecture we cannot share debug resources between QEMU and
> > guest because:
> >      When QEMU is using debug resources then debug exception must
> >      be always enabled. To achieve this we set MSR_DE and also set
> >      MSRP_DEP so guest cannot change MSR_DE.
> >
> >      When emulating debug resource for guest we want guest
> >      to control MSR_DE (enable/disable debug interrupt on need).
> >
> >      So above mentioned two configuration cannot be supported
> >      at the same time. So the result is that we cannot share
> >      debug resources between QEMU and Guest on BOOKE architecture.
> >
> > In the current design QEMU gets priority over guest, this means that
> > if QEMU is using debug resources then guest cannot use them and if
> > guest is using debug resource then QEMU can overwrite them.
> >
> > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > ---
> > Hi Alex,
> >
> > I thought of having some print in register emulation if QEMU is using
> > debug resource, Also when QEMU overwrites guest written values but
> > that looks excessive. If I uses some variable which get set when guest
> > starts using debug registers and check in debug set ioctl then that
> > look ugly. Looking for suggestions
> 
> Whatever you do, have QEMU do the print, not the kernel.
> 
> >
> >   arch/powerpc/include/asm/kvm_ppc.h |   3 +
> >   arch/powerpc/kvm/booke.c           |  27 +++++++
> >   arch/powerpc/kvm/booke_emulate.c   | 157
> +++++++++++++++++++++++++++++++++++++
> >   3 files changed, 187 insertions(+)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> > b/arch/powerpc/include/asm/kvm_ppc.h
> > index e2fd5a1..f3f7611 100644
> > --- a/arch/powerpc/include/asm/kvm_ppc.h
> > +++ b/arch/powerpc/include/asm/kvm_ppc.h
> > @@ -173,6 +173,9 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq,
> u32 *server,
> >   extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
> >   extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
> >
> > +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu); void
> > +kvmppc_core_queue_debug(struct kvm_vcpu *vcpu);
> > +
> >   union kvmppc_one_reg {
> >   	u32	wval;
> >   	u64	dval;
> > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c index
> > fadfe76..c2471ed 100644
> > --- a/arch/powerpc/kvm/booke.c
> > +++ b/arch/powerpc/kvm/booke.c
> > @@ -264,6 +264,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu
> *vcpu)
> >   	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
> >   }
> >
> > +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
> > +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
> > +
> > +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
> > +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions); }
> > +
> >   static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0, u32
> srr1)
> >   {
> >   #ifdef CONFIG_KVM_BOOKE_HV
> > @@ -783,6 +793,23 @@ static int kvmppc_handle_debug(struct kvm_run *run,
> struct kvm_vcpu *vcpu)
> >   	struct debug_reg *dbg_reg = &(vcpu->arch.shadow_dbg_reg);
> >   	u32 dbsr = vcpu->arch.dbsr;
> >
> > +	if (vcpu->guest_debug == 0) {
> > +		/* Debug resources belong to Guest */
> > +		if (dbsr && (vcpu->arch.shared->msr & MSR_DE))
> > +			kvmppc_core_queue_debug(vcpu);
> > +
> > +		/* Inject a program interrupt if trap debug is not allowed */
> > +		if ((dbsr & DBSR_TIE) && !(vcpu->arch.shared->msr & MSR_DE))
> > +			kvmppc_core_queue_program(vcpu, ESR_PTR);
> 
> In that case we would've received a program interrupt and never entered this
> code path, no?

Yes for HV.
But for PR we can be here, MSR_DE is set in h/w msr and guest MSR_DE is not set.
Having a ifdef does not look good but we can have a comment here.

Thanks
-Bharat

> 
> 
> Alex

RE: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat.Bhushan]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Monday, July 28, 2014 7:35 PM
> To: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org
> Cc: kvm@vger.kernel.org; Wood Scott-B07421; Yoder Stuart-B08248
> Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
> 
> 
> On 11.07.14 10:39, Bharat Bhushan wrote:
> > This patch emulates debug registers and debug exception to support
> > guest using debug resource. This enables running gdb/kgdb etc in
> > guest.
> >
> > On BOOKE architecture we cannot share debug resources between QEMU and
> > guest because:
> >      When QEMU is using debug resources then debug exception must
> >      be always enabled. To achieve this we set MSR_DE and also set
> >      MSRP_DEP so guest cannot change MSR_DE.
> >
> >      When emulating debug resource for guest we want guest
> >      to control MSR_DE (enable/disable debug interrupt on need).
> >
> >      So above mentioned two configuration cannot be supported
> >      at the same time. So the result is that we cannot share
> >      debug resources between QEMU and Guest on BOOKE architecture.
> >
> > In the current design QEMU gets priority over guest, this means that
> > if QEMU is using debug resources then guest cannot use them and if
> > guest is using debug resource then QEMU can overwrite them.
> >
> > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > ---
> > Hi Alex,
> >
> > I thought of having some print in register emulation if QEMU is using
> > debug resource, Also when QEMU overwrites guest written values but
> > that looks excessive. If I uses some variable which get set when guest
> > starts using debug registers and check in debug set ioctl then that
> > look ugly. Looking for suggestions
> 
> Whatever you do, have QEMU do the print, not the kernel.
> 
> >
> >   arch/powerpc/include/asm/kvm_ppc.h |   3 +
> >   arch/powerpc/kvm/booke.c           |  27 +++++++
> >   arch/powerpc/kvm/booke_emulate.c   | 157
> +++++++++++++++++++++++++++++++++++++
> >   3 files changed, 187 insertions(+)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> > b/arch/powerpc/include/asm/kvm_ppc.h
> > index e2fd5a1..f3f7611 100644
> > --- a/arch/powerpc/include/asm/kvm_ppc.h
> > +++ b/arch/powerpc/include/asm/kvm_ppc.h
> > @@ -173,6 +173,9 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq,
> u32 *server,
> >   extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
> >   extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
> >
> > +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu); void
> > +kvmppc_core_queue_debug(struct kvm_vcpu *vcpu);
> > +
> >   union kvmppc_one_reg {
> >   	u32	wval;
> >   	u64	dval;
> > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c index
> > fadfe76..c2471ed 100644
> > --- a/arch/powerpc/kvm/booke.c
> > +++ b/arch/powerpc/kvm/booke.c
> > @@ -264,6 +264,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu
> *vcpu)
> >   	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
> >   }
> >
> > +void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
> > +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
> > +
> > +void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
> > +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions); }
> > +
> >   static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0, u32
> srr1)
> >   {
> >   #ifdef CONFIG_KVM_BOOKE_HV
> > @@ -783,6 +793,23 @@ static int kvmppc_handle_debug(struct kvm_run *run,
> struct kvm_vcpu *vcpu)
> >   	struct debug_reg *dbg_reg = &(vcpu->arch.shadow_dbg_reg);
> >   	u32 dbsr = vcpu->arch.dbsr;
> >
> > +	if (vcpu->guest_debug = 0) {
> > +		/* Debug resources belong to Guest */
> > +		if (dbsr && (vcpu->arch.shared->msr & MSR_DE))
> > +			kvmppc_core_queue_debug(vcpu);
> > +
> > +		/* Inject a program interrupt if trap debug is not allowed */
> > +		if ((dbsr & DBSR_TIE) && !(vcpu->arch.shared->msr & MSR_DE))
> > +			kvmppc_core_queue_program(vcpu, ESR_PTR);
> 
> In that case we would've received a program interrupt and never entered this
> code path, no?

Yes for HV.
But for PR we can be here, MSR_DE is set in h/w msr and guest MSR_DE is not set.
Having a ifdef does not look good but we can have a comment here.

Thanks
-Bharat

> 
> 
> Alex

Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Scott Wood]

On Wed, 2014-07-30 at 00:21 -0500, Bhushan Bharat-R65777 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, July 29, 2014 3:22 AM
> > To: Bhushan Bharat-R65777
> > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> > B08248
> > Subject: Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest
> > visible register
> > 
> > On Fri, 2014-07-11 at 14:08 +0530, Bharat Bhushan wrote:
> > > This is not used and  even I do not remember why this was added in
> > > first place.
> > >
> > > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > > ---
> > >  arch/powerpc/kvm/booke.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c index
> > > ab62109..a5ee42c 100644
> > > --- a/arch/powerpc/kvm/booke.c
> > > +++ b/arch/powerpc/kvm/booke.c
> > > @@ -1804,8 +1804,6 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
> > *vcpu,
> > >  	kvm_guest_protect_msr(vcpu, MSR_DE, true);
> > >  	vcpu->guest_debug = dbg->control;
> > >  	vcpu->arch.shadow_dbg_reg.dbcr0 = 0;
> > > -	/* Set DBCR0_EDM in guest visible DBCR0 register. */
> > > -	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
> > >
> > >  	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
> > >  		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC;
> > 
> > This was intended to let the guest know that the host owns the debug resources,
> > by analogy to what a JTAG debugger would do.
> > 
> > The Power ISA has this "Virtualized Implementation Note":
> > 
> >         It is the responsibility of the hypervisor to ensure that
> >         DBCR0[EDM] is consistent with usage of DEP.
> 
> Ok, That means that if MSRP_DEP is set then set DBCR0_EDM  and if MSRP_DEP is clear then clear DBCR0_EDM, right?
> We need to implement above mentioned this.

We should probably clear EDM only when guest debug emulation is working
and enabled (i.e. not until at least patch 6/6).

-Scott

Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Scott Wood]

On Wed, 2014-07-30 at 00:21 -0500, Bhushan Bharat-R65777 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, July 29, 2014 3:22 AM
> > To: Bhushan Bharat-R65777
> > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> > B08248
> > Subject: Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest
> > visible register
> > 
> > On Fri, 2014-07-11 at 14:08 +0530, Bharat Bhushan wrote:
> > > This is not used and  even I do not remember why this was added in
> > > first place.
> > >
> > > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > > ---
> > >  arch/powerpc/kvm/booke.c | 2 --
> > >  1 file changed, 2 deletions(-)
> > >
> > > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c index
> > > ab62109..a5ee42c 100644
> > > --- a/arch/powerpc/kvm/booke.c
> > > +++ b/arch/powerpc/kvm/booke.c
> > > @@ -1804,8 +1804,6 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
> > *vcpu,
> > >  	kvm_guest_protect_msr(vcpu, MSR_DE, true);
> > >  	vcpu->guest_debug = dbg->control;
> > >  	vcpu->arch.shadow_dbg_reg.dbcr0 = 0;
> > > -	/* Set DBCR0_EDM in guest visible DBCR0 register. */
> > > -	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
> > >
> > >  	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
> > >  		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC;
> > 
> > This was intended to let the guest know that the host owns the debug resources,
> > by analogy to what a JTAG debugger would do.
> > 
> > The Power ISA has this "Virtualized Implementation Note":
> > 
> >         It is the responsibility of the hypervisor to ensure that
> >         DBCR0[EDM] is consistent with usage of DEP.
> 
> Ok, That means that if MSRP_DEP is set then set DBCR0_EDM  and if MSRP_DEP is clear then clear DBCR0_EDM, right?
> We need to implement above mentioned this.

We should probably clear EDM only when guest debug emulation is working
and enabled (i.e. not until at least patch 6/6).

-Scott

RE: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Bharat.Bhushan]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, July 30, 2014 11:18 PM
> To: Bhushan Bharat-R65777
> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> B08248
> Subject: Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest
> visible register
> 
> On Wed, 2014-07-30 at 00:21 -0500, Bhushan Bharat-R65777 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, July 29, 2014 3:22 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
> > > Yoder Stuart-
> > > B08248
> > > Subject: Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM
> > > in guest visible register
> > >
> > > On Fri, 2014-07-11 at 14:08 +0530, Bharat Bhushan wrote:
> > > > This is not used and  even I do not remember why this was added in
> > > > first place.
> > > >
> > > > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > > > ---
> > > >  arch/powerpc/kvm/booke.c | 2 --
> > > >  1 file changed, 2 deletions(-)
> > > >
> > > > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > > > index ab62109..a5ee42c 100644
> > > > --- a/arch/powerpc/kvm/booke.c
> > > > +++ b/arch/powerpc/kvm/booke.c
> > > > @@ -1804,8 +1804,6 @@ int
> > > > kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
> > > *vcpu,
> > > >  	kvm_guest_protect_msr(vcpu, MSR_DE, true);
> > > >  	vcpu->guest_debug = dbg->control;
> > > >  	vcpu->arch.shadow_dbg_reg.dbcr0 = 0;
> > > > -	/* Set DBCR0_EDM in guest visible DBCR0 register. */
> > > > -	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
> > > >
> > > >  	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
> > > >  		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC;
> > >
> > > This was intended to let the guest know that the host owns the debug
> > > resources, by analogy to what a JTAG debugger would do.
> > >
> > > The Power ISA has this "Virtualized Implementation Note":
> > >
> > >         It is the responsibility of the hypervisor to ensure that
> > >         DBCR0[EDM] is consistent with usage of DEP.
> >
> > Ok, That means that if MSRP_DEP is set then set DBCR0_EDM  and if MSRP_DEP is
> clear then clear DBCR0_EDM, right?
> > We need to implement above mentioned this.
> 
> We should probably clear EDM only when guest debug emulation is working and
> enabled (i.e. not until at least patch 6/6).

But if EDM is set then guest debug emulation will not start/allowed.


Thanks
-Bharat

> 
> -Scott
> 

RE: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Bharat.Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogV2VkbmVzZGF5LCBKdWx5IDMwLCAyMDE0IDExOjE4IFBNDQo+IFRvOiBCaHVz
aGFuIEJoYXJhdC1SNjU3NzcNCj4gQ2M6IGFncmFmQHN1c2UuZGU7IGt2bS1wcGNAdmdlci5rZXJu
ZWwub3JnOyBrdm1Admdlci5rZXJuZWwub3JnOyBZb2RlciBTdHVhcnQtDQo+IEIwODI0OA0KPiBT
dWJqZWN0OiBSZTogW1BBVENIIDEvNl0gS1ZNOiBQUEM6IEJPT0tFOiBObyBuZWVkIHRvIHNldCBE
QkNSMF9FRE0gaW4gZ3Vlc3QNCj4gdmlzaWJsZSByZWdpc3Rlcg0KPiANCj4gT24gV2VkLCAyMDE0
LTA3LTMwIGF0IDAwOjIxIC0wNTAwLCBCaHVzaGFuIEJoYXJhdC1SNjU3Nzcgd3JvdGU6DQo+ID4N
Cj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0
LUIwNzQyMQ0KPiA+ID4gU2VudDogVHVlc2RheSwgSnVseSAyOSwgMjAxNCAzOjIyIEFNDQo+ID4g
PiBUbzogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3DQo+ID4gPiBDYzogYWdyYWZAc3VzZS5kZTsga3Zt
LXBwY0B2Z2VyLmtlcm5lbC5vcmc7IGt2bUB2Z2VyLmtlcm5lbC5vcmc7DQo+ID4gPiBZb2RlciBT
dHVhcnQtDQo+ID4gPiBCMDgyNDgNCj4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMS82XSBLVk06
IFBQQzogQk9PS0U6IE5vIG5lZWQgdG8gc2V0IERCQ1IwX0VETQ0KPiA+ID4gaW4gZ3Vlc3Qgdmlz
aWJsZSByZWdpc3Rlcg0KPiA+ID4NCj4gPiA+IE9uIEZyaSwgMjAxNC0wNy0xMSBhdCAxNDowOCAr
MDUzMCwgQmhhcmF0IEJodXNoYW4gd3JvdGU6DQo+ID4gPiA+IFRoaXMgaXMgbm90IHVzZWQgYW5k
ICBldmVuIEkgZG8gbm90IHJlbWVtYmVyIHdoeSB0aGlzIHdhcyBhZGRlZCBpbg0KPiA+ID4gPiBm
aXJzdCBwbGFjZS4NCj4gPiA+ID4NCj4gPiA+ID4gU2lnbmVkLW9mZi1ieTogQmhhcmF0IEJodXNo
YW4gPEJoYXJhdC5CaHVzaGFuQGZyZWVzY2FsZS5jb20+DQo+ID4gPiA+IC0tLQ0KPiA+ID4gPiAg
YXJjaC9wb3dlcnBjL2t2bS9ib29rZS5jIHwgMiAtLQ0KPiA+ID4gPiAgMSBmaWxlIGNoYW5nZWQs
IDIgZGVsZXRpb25zKC0pDQo+ID4gPiA+DQo+ID4gPiA+IGRpZmYgLS1naXQgYS9hcmNoL3Bvd2Vy
cGMva3ZtL2Jvb2tlLmMgYi9hcmNoL3Bvd2VycGMva3ZtL2Jvb2tlLmMNCj4gPiA+ID4gaW5kZXgg
YWI2MjEwOS4uYTVlZTQyYyAxMDA2NDQNCj4gPiA+ID4gLS0tIGEvYXJjaC9wb3dlcnBjL2t2bS9i
b29rZS5jDQo+ID4gPiA+ICsrKyBiL2FyY2gvcG93ZXJwYy9rdm0vYm9va2UuYw0KPiA+ID4gPiBA
QCAtMTgwNCw4ICsxODA0LDYgQEAgaW50DQo+ID4gPiA+IGt2bV9hcmNoX3ZjcHVfaW9jdGxfc2V0
X2d1ZXN0X2RlYnVnKHN0cnVjdCBrdm1fdmNwdQ0KPiA+ID4gKnZjcHUsDQo+ID4gPiA+ICAJa3Zt
X2d1ZXN0X3Byb3RlY3RfbXNyKHZjcHUsIE1TUl9ERSwgdHJ1ZSk7DQo+ID4gPiA+ICAJdmNwdS0+
Z3Vlc3RfZGVidWcgPSBkYmctPmNvbnRyb2w7DQo+ID4gPiA+ICAJdmNwdS0+YXJjaC5zaGFkb3df
ZGJnX3JlZy5kYmNyMCA9IDA7DQo+ID4gPiA+IC0JLyogU2V0IERCQ1IwX0VETSBpbiBndWVzdCB2
aXNpYmxlIERCQ1IwIHJlZ2lzdGVyLiAqLw0KPiA+ID4gPiAtCXZjcHUtPmFyY2guZGJnX3JlZy5k
YmNyMCA9IERCQ1IwX0VETTsNCj4gPiA+ID4NCj4gPiA+ID4gIAlpZiAodmNwdS0+Z3Vlc3RfZGVi
dWcgJiBLVk1fR1VFU1REQkdfU0lOR0xFU1RFUCkNCj4gPiA+ID4gIAkJdmNwdS0+YXJjaC5zaGFk
b3dfZGJnX3JlZy5kYmNyMCB8PSBEQkNSMF9JRE0gfCBEQkNSMF9JQzsNCj4gPiA+DQo+ID4gPiBU
aGlzIHdhcyBpbnRlbmRlZCB0byBsZXQgdGhlIGd1ZXN0IGtub3cgdGhhdCB0aGUgaG9zdCBvd25z
IHRoZSBkZWJ1Zw0KPiA+ID4gcmVzb3VyY2VzLCBieSBhbmFsb2d5IHRvIHdoYXQgYSBKVEFHIGRl
YnVnZ2VyIHdvdWxkIGRvLg0KPiA+ID4NCj4gPiA+IFRoZSBQb3dlciBJU0EgaGFzIHRoaXMgIlZp
cnR1YWxpemVkIEltcGxlbWVudGF0aW9uIE5vdGUiOg0KPiA+ID4NCj4gPiA+ICAgICAgICAgSXQg
aXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBoeXBlcnZpc29yIHRvIGVuc3VyZSB0aGF0DQo+
ID4gPiAgICAgICAgIERCQ1IwW0VETV0gaXMgY29uc2lzdGVudCB3aXRoIHVzYWdlIG9mIERFUC4N
Cj4gPg0KPiA+IE9rLCBUaGF0IG1lYW5zIHRoYXQgaWYgTVNSUF9ERVAgaXMgc2V0IHRoZW4gc2V0
IERCQ1IwX0VETSAgYW5kIGlmIE1TUlBfREVQIGlzDQo+IGNsZWFyIHRoZW4gY2xlYXIgREJDUjBf
RURNLCByaWdodD8NCj4gPiBXZSBuZWVkIHRvIGltcGxlbWVudCBhYm92ZSBtZW50aW9uZWQgdGhp
cy4NCj4gDQo+IFdlIHNob3VsZCBwcm9iYWJseSBjbGVhciBFRE0gb25seSB3aGVuIGd1ZXN0IGRl
YnVnIGVtdWxhdGlvbiBpcyB3b3JraW5nIGFuZA0KPiBlbmFibGVkIChpLmUuIG5vdCB1bnRpbCBh
dCBsZWFzdCBwYXRjaCA2LzYpLg0KDQpCdXQgaWYgRURNIGlzIHNldCB0aGVuIGd1ZXN0IGRlYnVn
IGVtdWxhdGlvbiB3aWxsIG5vdCBzdGFydC9hbGxvd2VkLg0KDQoNClRoYW5rcw0KLUJoYXJhdA0K
DQo+IA0KPiAtU2NvdHQNCj4gDQoNCg=

Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Scott Wood]

On Wed, 2014-07-30 at 12:57 -0500, Bhushan Bharat-R65777 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, July 30, 2014 11:18 PM
> > To: Bhushan Bharat-R65777
> > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> > B08248
> > Subject: Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest
> > visible register
> > 
> > On Wed, 2014-07-30 at 00:21 -0500, Bhushan Bharat-R65777 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Tuesday, July 29, 2014 3:22 AM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
> > > > Yoder Stuart-
> > > > B08248
> > > > Subject: Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM
> > > > in guest visible register
> > > >
> > > > On Fri, 2014-07-11 at 14:08 +0530, Bharat Bhushan wrote:
> > > > > This is not used and  even I do not remember why this was added in
> > > > > first place.
> > > > >
> > > > > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > > > > ---
> > > > >  arch/powerpc/kvm/booke.c | 2 --
> > > > >  1 file changed, 2 deletions(-)
> > > > >
> > > > > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > > > > index ab62109..a5ee42c 100644
> > > > > --- a/arch/powerpc/kvm/booke.c
> > > > > +++ b/arch/powerpc/kvm/booke.c
> > > > > @@ -1804,8 +1804,6 @@ int
> > > > > kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
> > > > *vcpu,
> > > > >  	kvm_guest_protect_msr(vcpu, MSR_DE, true);
> > > > >  	vcpu->guest_debug = dbg->control;
> > > > >  	vcpu->arch.shadow_dbg_reg.dbcr0 = 0;
> > > > > -	/* Set DBCR0_EDM in guest visible DBCR0 register. */
> > > > > -	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
> > > > >
> > > > >  	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
> > > > >  		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC;
> > > >
> > > > This was intended to let the guest know that the host owns the debug
> > > > resources, by analogy to what a JTAG debugger would do.
> > > >
> > > > The Power ISA has this "Virtualized Implementation Note":
> > > >
> > > >         It is the responsibility of the hypervisor to ensure that
> > > >         DBCR0[EDM] is consistent with usage of DEP.
> > >
> > > Ok, That means that if MSRP_DEP is set then set DBCR0_EDM  and if MSRP_DEP is
> > clear then clear DBCR0_EDM, right?
> > > We need to implement above mentioned this.
> > 
> > We should probably clear EDM only when guest debug emulation is working and
> > enabled (i.e. not until at least patch 6/6).
> 
> But if EDM is set then guest debug emulation will not start/allowed.

I don't mean after the guest tries to write to the registers -- I mean
after the code has been added to KVM to allow it to work.

-Scott

Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest visible register

[Scott Wood]

On Wed, 2014-07-30 at 12:57 -0500, Bhushan Bharat-R65777 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Wednesday, July 30, 2014 11:18 PM
> > To: Bhushan Bharat-R65777
> > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> > B08248
> > Subject: Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM in guest
> > visible register
> > 
> > On Wed, 2014-07-30 at 00:21 -0500, Bhushan Bharat-R65777 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Tuesday, July 29, 2014 3:22 AM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
> > > > Yoder Stuart-
> > > > B08248
> > > > Subject: Re: [PATCH 1/6] KVM: PPC: BOOKE: No need to set DBCR0_EDM
> > > > in guest visible register
> > > >
> > > > On Fri, 2014-07-11 at 14:08 +0530, Bharat Bhushan wrote:
> > > > > This is not used and  even I do not remember why this was added in
> > > > > first place.
> > > > >
> > > > > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> > > > > ---
> > > > >  arch/powerpc/kvm/booke.c | 2 --
> > > > >  1 file changed, 2 deletions(-)
> > > > >
> > > > > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > > > > index ab62109..a5ee42c 100644
> > > > > --- a/arch/powerpc/kvm/booke.c
> > > > > +++ b/arch/powerpc/kvm/booke.c
> > > > > @@ -1804,8 +1804,6 @@ int
> > > > > kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
> > > > *vcpu,
> > > > >  	kvm_guest_protect_msr(vcpu, MSR_DE, true);
> > > > >  	vcpu->guest_debug = dbg->control;
> > > > >  	vcpu->arch.shadow_dbg_reg.dbcr0 = 0;
> > > > > -	/* Set DBCR0_EDM in guest visible DBCR0 register. */
> > > > > -	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
> > > > >
> > > > >  	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
> > > > >  		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC;
> > > >
> > > > This was intended to let the guest know that the host owns the debug
> > > > resources, by analogy to what a JTAG debugger would do.
> > > >
> > > > The Power ISA has this "Virtualized Implementation Note":
> > > >
> > > >         It is the responsibility of the hypervisor to ensure that
> > > >         DBCR0[EDM] is consistent with usage of DEP.
> > >
> > > Ok, That means that if MSRP_DEP is set then set DBCR0_EDM  and if MSRP_DEP is
> > clear then clear DBCR0_EDM, right?
> > > We need to implement above mentioned this.
> > 
> > We should probably clear EDM only when guest debug emulation is working and
> > enabled (i.e. not until at least patch 6/6).
> 
> But if EDM is set then guest debug emulation will not start/allowed.

I don't mean after the guest tries to write to the registers -- I mean
after the code has been added to KVM to allow it to work.

-Scott

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Wed, 2014-07-30 at 01:43 -0500, Bhushan Bharat-R65777 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, July 29, 2014 3:58 AM
> > To: Bhushan Bharat-R65777
> > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> > B08248
> > Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
> > 
> >  Userspace might be interested in
> > the raw value,
> 
> With the current design, If userspace is interested then it will not
> get the DBSR.

Oh, because DBSR isn't currently implemented in sregs or one reg?

>  But why userspace will be interested?

Do you expose all of the hardware's debugging features in your
high-level interface?

> > plus it's a change from the current API semantics.
> 
> Can you please let us know how ?

It looked like it was removing dbsr visibility and the requirement for
userspace to clear dbsr.  I guess the old way was that the value in
vcpu->arch.dbsr didn't matter until the next debug exception, when it
would be overwritten by the new SPRN_DBSR?

> > > +	case SPRN_DBCR2:
> > > +		/*
> > > +		 * If userspace is debugging guest then guest
> > > +		 * can not access debug registers.
> > > +		 */
> > > +		if (vcpu->guest_debug)
> > > +			break;
> > > +
> > > +		debug_inst = true;
> > > +		vcpu->arch.dbg_reg.dbcr2 = spr_val;
> > > +		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
> > >  		break;
> > 
> > In what circumstances can the architected and shadow registers differ?
> 
> As of now they are same. But I think that if we want to implement other features like "Freeze Timer (FT)" then they can be different.

I don't think we can possibly implement Freeze Timer.
 
> > >  	case SPRN_DBSR:
> > > +		/*
> > > +		 * If userspace is debugging guest then guest
> > > +		 * can not access debug registers.
> > > +		 */
> > > +		if (vcpu->guest_debug)
> > > +			break;
> > > +
> > >  		vcpu->arch.dbsr &= ~spr_val;
> > > +		if (vcpu->arch.dbsr == 0)
> > > +			kvmppc_core_dequeue_debug(vcpu);
> > >  		break;
> > 
> > Not all DBSR bits cause an exception, e.g. IDE and MRR.
> 
> I am not sure what we should in that case ?
>
> As we are currently emulating a subset of debug events (IAC, DAC, IC,
> BT and TIE --- DBCR0 emulation) then we should expose status of those
> events in guest dbsr and rest should be cleared ?

I'm not saying they need to be exposed to the guest, but I don't see
where you filter out bits like these.

> > > @@ -273,6 +397,10 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int
> > sprn, ulong spr_val)
> > >  		emulated = EMULATE_FAIL;
> > >  	}
> > >
> > > +	if (debug_inst) {
> > > +		switch_booke_debug_regs(&vcpu->arch.shadow_dbg_reg);
> > > +		current->thread.debug = vcpu->arch.shadow_dbg_reg;
> > > +	}
> > 
> > Could you explain what's going on with regard to copying the registers
> > into current->thread.debug?  Why is it done after loading the registers
> > into the hardware (is there a race if we get preempted in the middle)?
> 
> Yes, and this was something I was not clear when writing this code.
> Should we have preempt disable-enable around this.

Can they be reordered instead?

-Scott

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Wed, 2014-07-30 at 01:43 -0500, Bhushan Bharat-R65777 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, July 29, 2014 3:58 AM
> > To: Bhushan Bharat-R65777
> > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> > B08248
> > Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
> > 
> >  Userspace might be interested in
> > the raw value,
> 
> With the current design, If userspace is interested then it will not
> get the DBSR.

Oh, because DBSR isn't currently implemented in sregs or one reg?

>  But why userspace will be interested?

Do you expose all of the hardware's debugging features in your
high-level interface?

> > plus it's a change from the current API semantics.
> 
> Can you please let us know how ?

It looked like it was removing dbsr visibility and the requirement for
userspace to clear dbsr.  I guess the old way was that the value in
vcpu->arch.dbsr didn't matter until the next debug exception, when it
would be overwritten by the new SPRN_DBSR?

> > > +	case SPRN_DBCR2:
> > > +		/*
> > > +		 * If userspace is debugging guest then guest
> > > +		 * can not access debug registers.
> > > +		 */
> > > +		if (vcpu->guest_debug)
> > > +			break;
> > > +
> > > +		debug_inst = true;
> > > +		vcpu->arch.dbg_reg.dbcr2 = spr_val;
> > > +		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
> > >  		break;
> > 
> > In what circumstances can the architected and shadow registers differ?
> 
> As of now they are same. But I think that if we want to implement other features like "Freeze Timer (FT)" then they can be different.

I don't think we can possibly implement Freeze Timer.
 
> > >  	case SPRN_DBSR:
> > > +		/*
> > > +		 * If userspace is debugging guest then guest
> > > +		 * can not access debug registers.
> > > +		 */
> > > +		if (vcpu->guest_debug)
> > > +			break;
> > > +
> > >  		vcpu->arch.dbsr &= ~spr_val;
> > > +		if (vcpu->arch.dbsr = 0)
> > > +			kvmppc_core_dequeue_debug(vcpu);
> > >  		break;
> > 
> > Not all DBSR bits cause an exception, e.g. IDE and MRR.
> 
> I am not sure what we should in that case ?
>
> As we are currently emulating a subset of debug events (IAC, DAC, IC,
> BT and TIE --- DBCR0 emulation) then we should expose status of those
> events in guest dbsr and rest should be cleared ?

I'm not saying they need to be exposed to the guest, but I don't see
where you filter out bits like these.

> > > @@ -273,6 +397,10 @@ int kvmppc_booke_emulate_mtspr(struct kvm_vcpu *vcpu, int
> > sprn, ulong spr_val)
> > >  		emulated = EMULATE_FAIL;
> > >  	}
> > >
> > > +	if (debug_inst) {
> > > +		switch_booke_debug_regs(&vcpu->arch.shadow_dbg_reg);
> > > +		current->thread.debug = vcpu->arch.shadow_dbg_reg;
> > > +	}
> > 
> > Could you explain what's going on with regard to copying the registers
> > into current->thread.debug?  Why is it done after loading the registers
> > into the hardware (is there a race if we get preempted in the middle)?
> 
> Yes, and this was something I was not clear when writing this code.
> Should we have preempt disable-enable around this.

Can they be reordered instead?

-Scott

RE: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat.Bhushan]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Thursday, July 31, 2014 8:18 AM
> To: Bhushan Bharat-R65777
> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> B08248
> Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
> 
> On Wed, 2014-07-30 at 01:43 -0500, Bhushan Bharat-R65777 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Tuesday, July 29, 2014 3:58 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
> > > Yoder Stuart-
> > > B08248
> > > Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers
> > > and exception
> > >
> > >  Userspace might be interested in
> > > the raw value,
> >
> > With the current design, If userspace is interested then it will not
> > get the DBSR.
> 
> Oh, because DBSR isn't currently implemented in sregs or one reg?

That is one reason. Another is that if we give dbsr visibility to userspace then userspace have to clear dbsr in handling KVM_EXIT_DEBUG. And we think there is no gain in doing that because 
" 
- QEMU cannot inject debug interrupt to guest (as this does not know guest ability to handle debug interrupt; MSR_DE), so will always clear DBSR.
- If QEMU has to always clear DBSR in handling KVM_EXIT_DEBUG then this (clearing dbsr in kernel) avoid doing in SET_SREGS/set_one_reg()
" This makes dbsr not visible to userspace.

Also this (clearing of dbsr) should not be part of this patch, this should be a separate patch. I will do that in next version.

> 
> >  But why userspace will be interested?
> 
> Do you expose all of the hardware's debugging features in your high-level
> interface?

We support h/w breakpoint, watchpoint and IC (single stepping) and status in userspace exit provide all required information to userspace.

> 
> > > plus it's a change from the current API semantics.
> >
> > Can you please let us know how ?
> 
> It looked like it was removing dbsr visibility and the requirement for userspace
> to clear dbsr.  I guess the old way was that the value in
> vcpu->arch.dbsr didn't matter until the next debug exception, when it
> would be overwritten by the new SPRN_DBSR?

But that means old dbsr will be visibility to userspace, which is even bad than not visible, no?

Also this can lead to old dbsr visible to guest once userspace releases debug resources, but this can be solved by clearing dbsr in kvm_arch_vcpu_ioctl_set_guest_debug() -> " if (!(dbg->control & KVM_GUESTDBG_ENABLE)) { }".

> 
> > > > +	case SPRN_DBCR2:
> > > > +		/*
> > > > +		 * If userspace is debugging guest then guest
> > > > +		 * can not access debug registers.
> > > > +		 */
> > > > +		if (vcpu->guest_debug)
> > > > +			break;
> > > > +
> > > > +		debug_inst = true;
> > > > +		vcpu->arch.dbg_reg.dbcr2 = spr_val;
> > > > +		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
> > > >  		break;
> > >
> > > In what circumstances can the architected and shadow registers differ?
> >
> > As of now they are same. But I think that if we want to implement other
> features like "Freeze Timer (FT)" then they can be different.
> 
> I don't think we can possibly implement Freeze Timer.

May be, but in my opinion we should keep this open.

> 
> > > >  	case SPRN_DBSR:
> > > > +		/*
> > > > +		 * If userspace is debugging guest then guest
> > > > +		 * can not access debug registers.
> > > > +		 */
> > > > +		if (vcpu->guest_debug)
> > > > +			break;
> > > > +
> > > >  		vcpu->arch.dbsr &= ~spr_val;
> > > > +		if (vcpu->arch.dbsr == 0)
> > > > +			kvmppc_core_dequeue_debug(vcpu);
> > > >  		break;
> > >
> > > Not all DBSR bits cause an exception, e.g. IDE and MRR.
> >
> > I am not sure what we should in that case ?
> >
> > As we are currently emulating a subset of debug events (IAC, DAC, IC,
> > BT and TIE --- DBCR0 emulation) then we should expose status of those
> > events in guest dbsr and rest should be cleared ?
> 
> I'm not saying they need to be exposed to the guest, but I don't see where you
> filter out bits like these.

I am trying to get what all bits should be filtered out, all bits except IACx, DACx, IC, BT and TIE (same as event set filtering done when setting DBCR0) ? 

i.e IDE, UDE, MRR, IRPT, RET, CIRPT, CRET should be filtered out?

> 
> > > > @@ -273,6 +397,10 @@ int kvmppc_booke_emulate_mtspr(struct
> > > > kvm_vcpu *vcpu, int
> > > sprn, ulong spr_val)
> > > >  		emulated = EMULATE_FAIL;
> > > >  	}
> > > >
> > > > +	if (debug_inst) {
> > > > +		switch_booke_debug_regs(&vcpu->arch.shadow_dbg_reg);
> > > > +		current->thread.debug = vcpu->arch.shadow_dbg_reg;
> > > > +	}
> > >
> > > Could you explain what's going on with regard to copying the
> > > registers into current->thread.debug?  Why is it done after loading
> > > the registers into the hardware (is there a race if we get preempted in the
> middle)?
> >
> > Yes, and this was something I was not clear when writing this code.
> > Should we have preempt disable-enable around this.
> 
> Can they be reordered instead?

Thanks;  Yes, that will work :)


Regards
-Bharat

> 
> -Scott
> 

RE: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat.Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVGh1cnNkYXksIEp1bHkgMzEsIDIwMTQgODoxOCBBTQ0KPiBUbzogQmh1c2hh
biBCaGFyYXQtUjY1Nzc3DQo+IENjOiBhZ3JhZkBzdXNlLmRlOyBrdm0tcHBjQHZnZXIua2VybmVs
Lm9yZzsga3ZtQHZnZXIua2VybmVsLm9yZzsgWW9kZXIgU3R1YXJ0LQ0KPiBCMDgyNDgNCj4gU3Vi
amVjdDogUmU6IFtQQVRDSCA2LzZdIEtWTTogUFBDOiBCT09LRTogRW11bGF0ZSBkZWJ1ZyByZWdp
c3RlcnMgYW5kIGV4Y2VwdGlvbg0KPiANCj4gT24gV2VkLCAyMDE0LTA3LTMwIGF0IDAxOjQzIC0w
NTAwLCBCaHVzaGFuIEJoYXJhdC1SNjU3Nzcgd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2Vu
dDogVHVlc2RheSwgSnVseSAyOSwgMjAxNCAzOjU4IEFNDQo+ID4gPiBUbzogQmh1c2hhbiBCaGFy
YXQtUjY1Nzc3DQo+ID4gPiBDYzogYWdyYWZAc3VzZS5kZTsga3ZtLXBwY0B2Z2VyLmtlcm5lbC5v
cmc7IGt2bUB2Z2VyLmtlcm5lbC5vcmc7DQo+ID4gPiBZb2RlciBTdHVhcnQtDQo+ID4gPiBCMDgy
NDgNCj4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggNi82XSBLVk06IFBQQzogQk9PS0U6IEVtdWxh
dGUgZGVidWcgcmVnaXN0ZXJzDQo+ID4gPiBhbmQgZXhjZXB0aW9uDQo+ID4gPg0KPiA+ID4gIFVz
ZXJzcGFjZSBtaWdodCBiZSBpbnRlcmVzdGVkIGluDQo+ID4gPiB0aGUgcmF3IHZhbHVlLA0KPiA+
DQo+ID4gV2l0aCB0aGUgY3VycmVudCBkZXNpZ24sIElmIHVzZXJzcGFjZSBpcyBpbnRlcmVzdGVk
IHRoZW4gaXQgd2lsbCBub3QNCj4gPiBnZXQgdGhlIERCU1IuDQo+IA0KPiBPaCwgYmVjYXVzZSBE
QlNSIGlzbid0IGN1cnJlbnRseSBpbXBsZW1lbnRlZCBpbiBzcmVncyBvciBvbmUgcmVnPw0KDQpU
aGF0IGlzIG9uZSByZWFzb24uIEFub3RoZXIgaXMgdGhhdCBpZiB3ZSBnaXZlIGRic3IgdmlzaWJp
bGl0eSB0byB1c2Vyc3BhY2UgdGhlbiB1c2Vyc3BhY2UgaGF2ZSB0byBjbGVhciBkYnNyIGluIGhh
bmRsaW5nIEtWTV9FWElUX0RFQlVHLiBBbmQgd2UgdGhpbmsgdGhlcmUgaXMgbm8gZ2FpbiBpbiBk
b2luZyB0aGF0IGJlY2F1c2UgDQoiIA0KLSBRRU1VIGNhbm5vdCBpbmplY3QgZGVidWcgaW50ZXJy
dXB0IHRvIGd1ZXN0IChhcyB0aGlzIGRvZXMgbm90IGtub3cgZ3Vlc3QgYWJpbGl0eSB0byBoYW5k
bGUgZGVidWcgaW50ZXJydXB0OyBNU1JfREUpLCBzbyB3aWxsIGFsd2F5cyBjbGVhciBEQlNSLg0K
LSBJZiBRRU1VIGhhcyB0byBhbHdheXMgY2xlYXIgREJTUiBpbiBoYW5kbGluZyBLVk1fRVhJVF9E
RUJVRyB0aGVuIHRoaXMgKGNsZWFyaW5nIGRic3IgaW4ga2VybmVsKSBhdm9pZCBkb2luZyBpbiBT
RVRfU1JFR1Mvc2V0X29uZV9yZWcoKQ0KIiBUaGlzIG1ha2VzIGRic3Igbm90IHZpc2libGUgdG8g
dXNlcnNwYWNlLg0KDQpBbHNvIHRoaXMgKGNsZWFyaW5nIG9mIGRic3IpIHNob3VsZCBub3QgYmUg
cGFydCBvZiB0aGlzIHBhdGNoLCB0aGlzIHNob3VsZCBiZSBhIHNlcGFyYXRlIHBhdGNoLiBJIHdp
bGwgZG8gdGhhdCBpbiBuZXh0IHZlcnNpb24uDQoNCj4gDQo+ID4gIEJ1dCB3aHkgdXNlcnNwYWNl
IHdpbGwgYmUgaW50ZXJlc3RlZD8NCj4gDQo+IERvIHlvdSBleHBvc2UgYWxsIG9mIHRoZSBoYXJk
d2FyZSdzIGRlYnVnZ2luZyBmZWF0dXJlcyBpbiB5b3VyIGhpZ2gtbGV2ZWwNCj4gaW50ZXJmYWNl
Pw0KDQpXZSBzdXBwb3J0IGgvdyBicmVha3BvaW50LCB3YXRjaHBvaW50IGFuZCBJQyAoc2luZ2xl
IHN0ZXBwaW5nKSBhbmQgc3RhdHVzIGluIHVzZXJzcGFjZSBleGl0IHByb3ZpZGUgYWxsIHJlcXVp
cmVkIGluZm9ybWF0aW9uIHRvIHVzZXJzcGFjZS4NCg0KPiANCj4gPiA+IHBsdXMgaXQncyBhIGNo
YW5nZSBmcm9tIHRoZSBjdXJyZW50IEFQSSBzZW1hbnRpY3MuDQo+ID4NCj4gPiBDYW4geW91IHBs
ZWFzZSBsZXQgdXMga25vdyBob3cgPw0KPiANCj4gSXQgbG9va2VkIGxpa2UgaXQgd2FzIHJlbW92
aW5nIGRic3IgdmlzaWJpbGl0eSBhbmQgdGhlIHJlcXVpcmVtZW50IGZvciB1c2Vyc3BhY2UNCj4g
dG8gY2xlYXIgZGJzci4gIEkgZ3Vlc3MgdGhlIG9sZCB3YXkgd2FzIHRoYXQgdGhlIHZhbHVlIGlu
DQo+IHZjcHUtPmFyY2guZGJzciBkaWRuJ3QgbWF0dGVyIHVudGlsIHRoZSBuZXh0IGRlYnVnIGV4
Y2VwdGlvbiwgd2hlbiBpdA0KPiB3b3VsZCBiZSBvdmVyd3JpdHRlbiBieSB0aGUgbmV3IFNQUk5f
REJTUj8NCg0KQnV0IHRoYXQgbWVhbnMgb2xkIGRic3Igd2lsbCBiZSB2aXNpYmlsaXR5IHRvIHVz
ZXJzcGFjZSwgd2hpY2ggaXMgZXZlbiBiYWQgdGhhbiBub3QgdmlzaWJsZSwgbm8/DQoNCkFsc28g
dGhpcyBjYW4gbGVhZCB0byBvbGQgZGJzciB2aXNpYmxlIHRvIGd1ZXN0IG9uY2UgdXNlcnNwYWNl
IHJlbGVhc2VzIGRlYnVnIHJlc291cmNlcywgYnV0IHRoaXMgY2FuIGJlIHNvbHZlZCBieSBjbGVh
cmluZyBkYnNyIGluIGt2bV9hcmNoX3ZjcHVfaW9jdGxfc2V0X2d1ZXN0X2RlYnVnKCkgLT4gIiBp
ZiAoIShkYmctPmNvbnRyb2wgJiBLVk1fR1VFU1REQkdfRU5BQkxFKSkgeyB9Ii4NCg0KPiANCj4g
PiA+ID4gKwljYXNlIFNQUk5fREJDUjI6DQo+ID4gPiA+ICsJCS8qDQo+ID4gPiA+ICsJCSAqIElm
IHVzZXJzcGFjZSBpcyBkZWJ1Z2dpbmcgZ3Vlc3QgdGhlbiBndWVzdA0KPiA+ID4gPiArCQkgKiBj
YW4gbm90IGFjY2VzcyBkZWJ1ZyByZWdpc3RlcnMuDQo+ID4gPiA+ICsJCSAqLw0KPiA+ID4gPiAr
CQlpZiAodmNwdS0+Z3Vlc3RfZGVidWcpDQo+ID4gPiA+ICsJCQlicmVhazsNCj4gPiA+ID4gKw0K
PiA+ID4gPiArCQlkZWJ1Z19pbnN0ID0gdHJ1ZTsNCj4gPiA+ID4gKwkJdmNwdS0+YXJjaC5kYmdf
cmVnLmRiY3IyID0gc3ByX3ZhbDsNCj4gPiA+ID4gKwkJdmNwdS0+YXJjaC5zaGFkb3dfZGJnX3Jl
Zy5kYmNyMiA9IHNwcl92YWw7DQo+ID4gPiA+ICAJCWJyZWFrOw0KPiA+ID4NCj4gPiA+IEluIHdo
YXQgY2lyY3Vtc3RhbmNlcyBjYW4gdGhlIGFyY2hpdGVjdGVkIGFuZCBzaGFkb3cgcmVnaXN0ZXJz
IGRpZmZlcj8NCj4gPg0KPiA+IEFzIG9mIG5vdyB0aGV5IGFyZSBzYW1lLiBCdXQgSSB0aGluayB0
aGF0IGlmIHdlIHdhbnQgdG8gaW1wbGVtZW50IG90aGVyDQo+IGZlYXR1cmVzIGxpa2UgIkZyZWV6
ZSBUaW1lciAoRlQpIiB0aGVuIHRoZXkgY2FuIGJlIGRpZmZlcmVudC4NCj4gDQo+IEkgZG9uJ3Qg
dGhpbmsgd2UgY2FuIHBvc3NpYmx5IGltcGxlbWVudCBGcmVlemUgVGltZXIuDQoNCk1heSBiZSwg
YnV0IGluIG15IG9waW5pb24gd2Ugc2hvdWxkIGtlZXAgdGhpcyBvcGVuLg0KDQo+IA0KPiA+ID4g
PiAgCWNhc2UgU1BSTl9EQlNSOg0KPiA+ID4gPiArCQkvKg0KPiA+ID4gPiArCQkgKiBJZiB1c2Vy
c3BhY2UgaXMgZGVidWdnaW5nIGd1ZXN0IHRoZW4gZ3Vlc3QNCj4gPiA+ID4gKwkJICogY2FuIG5v
dCBhY2Nlc3MgZGVidWcgcmVnaXN0ZXJzLg0KPiA+ID4gPiArCQkgKi8NCj4gPiA+ID4gKwkJaWYg
KHZjcHUtPmd1ZXN0X2RlYnVnKQ0KPiA+ID4gPiArCQkJYnJlYWs7DQo+ID4gPiA+ICsNCj4gPiA+
ID4gIAkJdmNwdS0+YXJjaC5kYnNyICY9IH5zcHJfdmFsOw0KPiA+ID4gPiArCQlpZiAodmNwdS0+
YXJjaC5kYnNyID09IDApDQo+ID4gPiA+ICsJCQlrdm1wcGNfY29yZV9kZXF1ZXVlX2RlYnVnKHZj
cHUpOw0KPiA+ID4gPiAgCQlicmVhazsNCj4gPiA+DQo+ID4gPiBOb3QgYWxsIERCU1IgYml0cyBj
YXVzZSBhbiBleGNlcHRpb24sIGUuZy4gSURFIGFuZCBNUlIuDQo+ID4NCj4gPiBJIGFtIG5vdCBz
dXJlIHdoYXQgd2Ugc2hvdWxkIGluIHRoYXQgY2FzZSA/DQo+ID4NCj4gPiBBcyB3ZSBhcmUgY3Vy
cmVudGx5IGVtdWxhdGluZyBhIHN1YnNldCBvZiBkZWJ1ZyBldmVudHMgKElBQywgREFDLCBJQywN
Cj4gPiBCVCBhbmQgVElFIC0tLSBEQkNSMCBlbXVsYXRpb24pIHRoZW4gd2Ugc2hvdWxkIGV4cG9z
ZSBzdGF0dXMgb2YgdGhvc2UNCj4gPiBldmVudHMgaW4gZ3Vlc3QgZGJzciBhbmQgcmVzdCBzaG91
bGQgYmUgY2xlYXJlZCA/DQo+IA0KPiBJJ20gbm90IHNheWluZyB0aGV5IG5lZWQgdG8gYmUgZXhw
b3NlZCB0byB0aGUgZ3Vlc3QsIGJ1dCBJIGRvbid0IHNlZSB3aGVyZSB5b3UNCj4gZmlsdGVyIG91
dCBiaXRzIGxpa2UgdGhlc2UuDQoNCkkgYW0gdHJ5aW5nIHRvIGdldCB3aGF0IGFsbCBiaXRzIHNo
b3VsZCBiZSBmaWx0ZXJlZCBvdXQsIGFsbCBiaXRzIGV4Y2VwdCBJQUN4LCBEQUN4LCBJQywgQlQg
YW5kIFRJRSAoc2FtZSBhcyBldmVudCBzZXQgZmlsdGVyaW5nIGRvbmUgd2hlbiBzZXR0aW5nIERC
Q1IwKSA/IA0KDQppLmUgSURFLCBVREUsIE1SUiwgSVJQVCwgUkVULCBDSVJQVCwgQ1JFVCBzaG91
bGQgYmUgZmlsdGVyZWQgb3V0Pw0KDQo+IA0KPiA+ID4gPiBAQCAtMjczLDYgKzM5NywxMCBAQCBp
bnQga3ZtcHBjX2Jvb2tlX2VtdWxhdGVfbXRzcHIoc3RydWN0DQo+ID4gPiA+IGt2bV92Y3B1ICp2
Y3B1LCBpbnQNCj4gPiA+IHNwcm4sIHVsb25nIHNwcl92YWwpDQo+ID4gPiA+ICAJCWVtdWxhdGVk
ID0gRU1VTEFURV9GQUlMOw0KPiA+ID4gPiAgCX0NCj4gPiA+ID4NCj4gPiA+ID4gKwlpZiAoZGVi
dWdfaW5zdCkgew0KPiA+ID4gPiArCQlzd2l0Y2hfYm9va2VfZGVidWdfcmVncygmdmNwdS0+YXJj
aC5zaGFkb3dfZGJnX3JlZyk7DQo+ID4gPiA+ICsJCWN1cnJlbnQtPnRocmVhZC5kZWJ1ZyA9IHZj
cHUtPmFyY2guc2hhZG93X2RiZ19yZWc7DQo+ID4gPiA+ICsJfQ0KPiA+ID4NCj4gPiA+IENvdWxk
IHlvdSBleHBsYWluIHdoYXQncyBnb2luZyBvbiB3aXRoIHJlZ2FyZCB0byBjb3B5aW5nIHRoZQ0K
PiA+ID4gcmVnaXN0ZXJzIGludG8gY3VycmVudC0+dGhyZWFkLmRlYnVnPyAgV2h5IGlzIGl0IGRv
bmUgYWZ0ZXIgbG9hZGluZw0KPiA+ID4gdGhlIHJlZ2lzdGVycyBpbnRvIHRoZSBoYXJkd2FyZSAo
aXMgdGhlcmUgYSByYWNlIGlmIHdlIGdldCBwcmVlbXB0ZWQgaW4gdGhlDQo+IG1pZGRsZSk/DQo+
ID4NCj4gPiBZZXMsIGFuZCB0aGlzIHdhcyBzb21ldGhpbmcgSSB3YXMgbm90IGNsZWFyIHdoZW4g
d3JpdGluZyB0aGlzIGNvZGUuDQo+ID4gU2hvdWxkIHdlIGhhdmUgcHJlZW1wdCBkaXNhYmxlLWVu
YWJsZSBhcm91bmQgdGhpcy4NCj4gDQo+IENhbiB0aGV5IGJlIHJlb3JkZXJlZCBpbnN0ZWFkPw0K
DQpUaGFua3M7ICBZZXMsIHRoYXQgd2lsbCB3b3JrIDopDQoNCg0KUmVnYXJkcw0KLUJoYXJhdA0K
DQo+IA0KPiAtU2NvdHQNCj4gDQoNCg=

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Thu, 2014-07-31 at 01:15 -0500, Bhushan Bharat-R65777 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, July 31, 2014 8:18 AM
> > To: Bhushan Bharat-R65777
> > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> > B08248
> > Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
> > 
> > On Wed, 2014-07-30 at 01:43 -0500, Bhushan Bharat-R65777 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Tuesday, July 29, 2014 3:58 AM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
> > > > Yoder Stuart-
> > > > B08248
> > > > Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers
> > > > and exception
> > > >
> > > >  Userspace might be interested in
> > > > the raw value,
> > >
> > > With the current design, If userspace is interested then it will not
> > > get the DBSR.
> > 
> > Oh, because DBSR isn't currently implemented in sregs or one reg?
> 
> That is one reason. Another is that if we give dbsr visibility to
> userspace then userspace have to clear dbsr in handling KVM_EXIT_DEBUG.

Right -- since I didn't realize DBSR wasn't already exposed, I thought
userspace already had this responsibility.

> > It looked like it was removing dbsr visibility and the requirement for userspace
> > to clear dbsr.  I guess the old way was that the value in
> > vcpu->arch.dbsr didn't matter until the next debug exception, when it
> > would be overwritten by the new SPRN_DBSR?
> 
> But that means old dbsr will be visibility to userspace, which is even bad than not visible, no?
> 
> Also this can lead to old dbsr visible to guest once userspace releases
> debug resources, but this can be solved by clearing dbsr in
> kvm_arch_vcpu_ioctl_set_guest_debug() -> " if (!(dbg->control &
> KVM_GUESTDBG_ENABLE)) { }".

I wasn't suggesting that you keep it that way, just clarifying my
understanding of the current code.


> 
> > 
> > > > > +	case SPRN_DBCR2:
> > > > > +		/*
> > > > > +		 * If userspace is debugging guest then guest
> > > > > +		 * can not access debug registers.
> > > > > +		 */
> > > > > +		if (vcpu->guest_debug)
> > > > > +			break;
> > > > > +
> > > > > +		debug_inst = true;
> > > > > +		vcpu->arch.dbg_reg.dbcr2 = spr_val;
> > > > > +		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
> > > > >  		break;
> > > >
> > > > In what circumstances can the architected and shadow registers differ?
> > >
> > > As of now they are same. But I think that if we want to implement other
> > features like "Freeze Timer (FT)" then they can be different.
> > 
> > I don't think we can possibly implement Freeze Timer.
> 
> May be, but in my opinion we should keep this open.

We're not talking about API here -- the implementation should be kept
simple if there's no imminent need for shadow registers.

> > > I am not sure what we should in that case ?
> > >
> > > As we are currently emulating a subset of debug events (IAC, DAC, IC,
> > > BT and TIE --- DBCR0 emulation) then we should expose status of those
> > > events in guest dbsr and rest should be cleared ?
> > 
> > I'm not saying they need to be exposed to the guest, but I don't see where you
> > filter out bits like these.
> 
> I am trying to get what all bits should be filtered out, all bits
> except IACx, DACx, IC, BT and TIE (same as event set filtering done
> when setting DBCR0) ? 
> 
> i.e IDE, UDE, MRR, IRPT, RET, CIRPT, CRET should be filtered out?

Bits like IRPT and RET don't really matter, as you shouldn't see them
happen.  Likewise MRR if you're sure you've cleared it since boot.  But
IDE could be set any time an asynchronous exception happens.  I don't
think you should filter it out, but instead make sure that it doesn't
cause an exception to be delivered.

-Scott

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Thu, 2014-07-31 at 01:15 -0500, Bhushan Bharat-R65777 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, July 31, 2014 8:18 AM
> > To: Bhushan Bharat-R65777
> > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> > B08248
> > Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
> > 
> > On Wed, 2014-07-30 at 01:43 -0500, Bhushan Bharat-R65777 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Tuesday, July 29, 2014 3:58 AM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
> > > > Yoder Stuart-
> > > > B08248
> > > > Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers
> > > > and exception
> > > >
> > > >  Userspace might be interested in
> > > > the raw value,
> > >
> > > With the current design, If userspace is interested then it will not
> > > get the DBSR.
> > 
> > Oh, because DBSR isn't currently implemented in sregs or one reg?
> 
> That is one reason. Another is that if we give dbsr visibility to
> userspace then userspace have to clear dbsr in handling KVM_EXIT_DEBUG.

Right -- since I didn't realize DBSR wasn't already exposed, I thought
userspace already had this responsibility.

> > It looked like it was removing dbsr visibility and the requirement for userspace
> > to clear dbsr.  I guess the old way was that the value in
> > vcpu->arch.dbsr didn't matter until the next debug exception, when it
> > would be overwritten by the new SPRN_DBSR?
> 
> But that means old dbsr will be visibility to userspace, which is even bad than not visible, no?
> 
> Also this can lead to old dbsr visible to guest once userspace releases
> debug resources, but this can be solved by clearing dbsr in
> kvm_arch_vcpu_ioctl_set_guest_debug() -> " if (!(dbg->control &
> KVM_GUESTDBG_ENABLE)) { }".

I wasn't suggesting that you keep it that way, just clarifying my
understanding of the current code.


> 
> > 
> > > > > +	case SPRN_DBCR2:
> > > > > +		/*
> > > > > +		 * If userspace is debugging guest then guest
> > > > > +		 * can not access debug registers.
> > > > > +		 */
> > > > > +		if (vcpu->guest_debug)
> > > > > +			break;
> > > > > +
> > > > > +		debug_inst = true;
> > > > > +		vcpu->arch.dbg_reg.dbcr2 = spr_val;
> > > > > +		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
> > > > >  		break;
> > > >
> > > > In what circumstances can the architected and shadow registers differ?
> > >
> > > As of now they are same. But I think that if we want to implement other
> > features like "Freeze Timer (FT)" then they can be different.
> > 
> > I don't think we can possibly implement Freeze Timer.
> 
> May be, but in my opinion we should keep this open.

We're not talking about API here -- the implementation should be kept
simple if there's no imminent need for shadow registers.

> > > I am not sure what we should in that case ?
> > >
> > > As we are currently emulating a subset of debug events (IAC, DAC, IC,
> > > BT and TIE --- DBCR0 emulation) then we should expose status of those
> > > events in guest dbsr and rest should be cleared ?
> > 
> > I'm not saying they need to be exposed to the guest, but I don't see where you
> > filter out bits like these.
> 
> I am trying to get what all bits should be filtered out, all bits
> except IACx, DACx, IC, BT and TIE (same as event set filtering done
> when setting DBCR0) ? 
> 
> i.e IDE, UDE, MRR, IRPT, RET, CIRPT, CRET should be filtered out?

Bits like IRPT and RET don't really matter, as you shouldn't see them
happen.  Likewise MRR if you're sure you've cleared it since boot.  But
IDE could be set any time an asynchronous exception happens.  I don't
think you should filter it out, but instead make sure that it doesn't
cause an exception to be delivered.

-Scott

RE: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat.Bhushan]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, August 01, 2014 2:16 AM
> To: Bhushan Bharat-R65777
> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder Stuart-
> B08248
> Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception
> 
> On Thu, 2014-07-31 at 01:15 -0500, Bhushan Bharat-R65777 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Thursday, July 31, 2014 8:18 AM
> > > To: Bhushan Bharat-R65777
> > > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; Yoder
> Stuart-
> > > B08248
> > > Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and
> exception
> > >
> > > On Wed, 2014-07-30 at 01:43 -0500, Bhushan Bharat-R65777 wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Tuesday, July 29, 2014 3:58 AM
> > > > > To: Bhushan Bharat-R65777
> > > > > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
> > > > > Yoder Stuart-
> > > > > B08248
> > > > > Subject: Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers
> > > > > and exception
> > > > >
> > > > >  Userspace might be interested in
> > > > > the raw value,
> > > >
> > > > With the current design, If userspace is interested then it will not
> > > > get the DBSR.
> > >
> > > Oh, because DBSR isn't currently implemented in sregs or one reg?
> >
> > That is one reason. Another is that if we give dbsr visibility to
> > userspace then userspace have to clear dbsr in handling KVM_EXIT_DEBUG.
> 
> Right -- since I didn't realize DBSR wasn't already exposed, I thought
> userspace already had this responsibility.
> 
> > > It looked like it was removing dbsr visibility and the requirement for
> userspace
> > > to clear dbsr.  I guess the old way was that the value in
> > > vcpu->arch.dbsr didn't matter until the next debug exception, when it
> > > would be overwritten by the new SPRN_DBSR?
> >
> > But that means old dbsr will be visibility to userspace, which is even bad
> than not visible, no?
> >
> > Also this can lead to old dbsr visible to guest once userspace releases
> > debug resources, but this can be solved by clearing dbsr in
> > kvm_arch_vcpu_ioctl_set_guest_debug() -> " if (!(dbg->control &
> > KVM_GUESTDBG_ENABLE)) { }".
> 
> I wasn't suggesting that you keep it that way, just clarifying my
> understanding of the current code.
> 
> 
> >
> > >
> > > > > > +	case SPRN_DBCR2:
> > > > > > +		/*
> > > > > > +		 * If userspace is debugging guest then guest
> > > > > > +		 * can not access debug registers.
> > > > > > +		 */
> > > > > > +		if (vcpu->guest_debug)
> > > > > > +			break;
> > > > > > +
> > > > > > +		debug_inst = true;
> > > > > > +		vcpu->arch.dbg_reg.dbcr2 = spr_val;
> > > > > > +		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
> > > > > >  		break;
> > > > >
> > > > > In what circumstances can the architected and shadow registers differ?
> > > >
> > > > As of now they are same. But I think that if we want to implement other
> > > features like "Freeze Timer (FT)" then they can be different.
> > >
> > > I don't think we can possibly implement Freeze Timer.
> >
> > May be, but in my opinion we should keep this open.
> 
> We're not talking about API here -- the implementation should be kept
> simple if there's no imminent need for shadow registers.
> 
> > > > I am not sure what we should in that case ?
> > > >
> > > > As we are currently emulating a subset of debug events (IAC, DAC, IC,
> > > > BT and TIE --- DBCR0 emulation) then we should expose status of those
> > > > events in guest dbsr and rest should be cleared ?
> > >
> > > I'm not saying they need to be exposed to the guest, but I don't see where
> you
> > > filter out bits like these.
> >
> > I am trying to get what all bits should be filtered out, all bits
> > except IACx, DACx, IC, BT and TIE (same as event set filtering done
> > when setting DBCR0) ?
> >
> > i.e IDE, UDE, MRR, IRPT, RET, CIRPT, CRET should be filtered out?
> 
> Bits like IRPT and RET don't really matter, as you shouldn't see them
> happen.  Likewise MRR if you're sure you've cleared it since boot.

We can clear MRR bits when update vcpu->arch->dbsr with SPRM_DBSR in kvm debug handler

>  But
> IDE could be set any time an asynchronous exception happens.  I don't
> think you should filter it out, but instead make sure that it doesn't
> cause an exception to be delivered.

So this means that in kvmpp_handle_debug() if DBSR_IDE is set then do not inject debug interrupt 

 and

on dbsr write emulation, deque the debug interrupt even if DBSR_IDE is set.

        case SPRN_DBSR:

                vcpu->arch.dbsr &= ~spr_val;
                if (!(vcpu->arch.dbsr & ~DBSR_IDE))
                        kvmppc_core_dequeue_debug(vcpu);
                break;

or
                vcpu->arch.dbsr &= ~(spr_val | DBSR_IDE);
                if (!vcpu->arch.dbsr)
                        kvmppc_core_dequeue_debug(vcpu);
                break;

Thanks
-Bharat

> 
> -Scott
> 

RE: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Bharat.Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBBdWd1c3QgMDEsIDIwMTQgMjoxNiBBTQ0KPiBUbzogQmh1c2hh
biBCaGFyYXQtUjY1Nzc3DQo+IENjOiBhZ3JhZkBzdXNlLmRlOyBrdm0tcHBjQHZnZXIua2VybmVs
Lm9yZzsga3ZtQHZnZXIua2VybmVsLm9yZzsgWW9kZXIgU3R1YXJ0LQ0KPiBCMDgyNDgNCj4gU3Vi
amVjdDogUmU6IFtQQVRDSCA2LzZdIEtWTTogUFBDOiBCT09LRTogRW11bGF0ZSBkZWJ1ZyByZWdp
c3RlcnMgYW5kIGV4Y2VwdGlvbg0KPiANCj4gT24gVGh1LCAyMDE0LTA3LTMxIGF0IDAxOjE1IC0w
NTAwLCBCaHVzaGFuIEJoYXJhdC1SNjU3Nzcgd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2Vu
dDogVGh1cnNkYXksIEp1bHkgMzEsIDIwMTQgODoxOCBBTQ0KPiA+ID4gVG86IEJodXNoYW4gQmhh
cmF0LVI2NTc3Nw0KPiA+ID4gQ2M6IGFncmFmQHN1c2UuZGU7IGt2bS1wcGNAdmdlci5rZXJuZWwu
b3JnOyBrdm1Admdlci5rZXJuZWwub3JnOyBZb2Rlcg0KPiBTdHVhcnQtDQo+ID4gPiBCMDgyNDgN
Cj4gPiA+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggNi82XSBLVk06IFBQQzogQk9PS0U6IEVtdWxhdGUg
ZGVidWcgcmVnaXN0ZXJzIGFuZA0KPiBleGNlcHRpb24NCj4gPiA+DQo+ID4gPiBPbiBXZWQsIDIw
MTQtMDctMzAgYXQgMDE6NDMgLTA1MDAsIEJodXNoYW4gQmhhcmF0LVI2NTc3NyB3cm90ZToNCj4g
PiA+ID4NCj4gPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZy
b206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiA+ID4gU2VudDogVHVlc2RheSwgSnVseSAyOSwg
MjAxNCAzOjU4IEFNDQo+ID4gPiA+ID4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiA+ID4g
PiA+IENjOiBhZ3JhZkBzdXNlLmRlOyBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsga3ZtQHZnZXIu
a2VybmVsLm9yZzsNCj4gPiA+ID4gPiBZb2RlciBTdHVhcnQtDQo+ID4gPiA+ID4gQjA4MjQ4DQo+
ID4gPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSCA2LzZdIEtWTTogUFBDOiBCT09LRTogRW11bGF0
ZSBkZWJ1ZyByZWdpc3RlcnMNCj4gPiA+ID4gPiBhbmQgZXhjZXB0aW9uDQo+ID4gPiA+ID4NCj4g
PiA+ID4gPiAgVXNlcnNwYWNlIG1pZ2h0IGJlIGludGVyZXN0ZWQgaW4NCj4gPiA+ID4gPiB0aGUg
cmF3IHZhbHVlLA0KPiA+ID4gPg0KPiA+ID4gPiBXaXRoIHRoZSBjdXJyZW50IGRlc2lnbiwgSWYg
dXNlcnNwYWNlIGlzIGludGVyZXN0ZWQgdGhlbiBpdCB3aWxsIG5vdA0KPiA+ID4gPiBnZXQgdGhl
IERCU1IuDQo+ID4gPg0KPiA+ID4gT2gsIGJlY2F1c2UgREJTUiBpc24ndCBjdXJyZW50bHkgaW1w
bGVtZW50ZWQgaW4gc3JlZ3Mgb3Igb25lIHJlZz8NCj4gPg0KPiA+IFRoYXQgaXMgb25lIHJlYXNv
bi4gQW5vdGhlciBpcyB0aGF0IGlmIHdlIGdpdmUgZGJzciB2aXNpYmlsaXR5IHRvDQo+ID4gdXNl
cnNwYWNlIHRoZW4gdXNlcnNwYWNlIGhhdmUgdG8gY2xlYXIgZGJzciBpbiBoYW5kbGluZyBLVk1f
RVhJVF9ERUJVRy4NCj4gDQo+IFJpZ2h0IC0tIHNpbmNlIEkgZGlkbid0IHJlYWxpemUgREJTUiB3
YXNuJ3QgYWxyZWFkeSBleHBvc2VkLCBJIHRob3VnaHQNCj4gdXNlcnNwYWNlIGFscmVhZHkgaGFk
IHRoaXMgcmVzcG9uc2liaWxpdHkuDQo+IA0KPiA+ID4gSXQgbG9va2VkIGxpa2UgaXQgd2FzIHJl
bW92aW5nIGRic3IgdmlzaWJpbGl0eSBhbmQgdGhlIHJlcXVpcmVtZW50IGZvcg0KPiB1c2Vyc3Bh
Y2UNCj4gPiA+IHRvIGNsZWFyIGRic3IuICBJIGd1ZXNzIHRoZSBvbGQgd2F5IHdhcyB0aGF0IHRo
ZSB2YWx1ZSBpbg0KPiA+ID4gdmNwdS0+YXJjaC5kYnNyIGRpZG4ndCBtYXR0ZXIgdW50aWwgdGhl
IG5leHQgZGVidWcgZXhjZXB0aW9uLCB3aGVuIGl0DQo+ID4gPiB3b3VsZCBiZSBvdmVyd3JpdHRl
biBieSB0aGUgbmV3IFNQUk5fREJTUj8NCj4gPg0KPiA+IEJ1dCB0aGF0IG1lYW5zIG9sZCBkYnNy
IHdpbGwgYmUgdmlzaWJpbGl0eSB0byB1c2Vyc3BhY2UsIHdoaWNoIGlzIGV2ZW4gYmFkDQo+IHRo
YW4gbm90IHZpc2libGUsIG5vPw0KPiA+DQo+ID4gQWxzbyB0aGlzIGNhbiBsZWFkIHRvIG9sZCBk
YnNyIHZpc2libGUgdG8gZ3Vlc3Qgb25jZSB1c2Vyc3BhY2UgcmVsZWFzZXMNCj4gPiBkZWJ1ZyBy
ZXNvdXJjZXMsIGJ1dCB0aGlzIGNhbiBiZSBzb2x2ZWQgYnkgY2xlYXJpbmcgZGJzciBpbg0KPiA+
IGt2bV9hcmNoX3ZjcHVfaW9jdGxfc2V0X2d1ZXN0X2RlYnVnKCkgLT4gIiBpZiAoIShkYmctPmNv
bnRyb2wgJg0KPiA+IEtWTV9HVUVTVERCR19FTkFCTEUpKSB7IH0iLg0KPiANCj4gSSB3YXNuJ3Qg
c3VnZ2VzdGluZyB0aGF0IHlvdSBrZWVwIGl0IHRoYXQgd2F5LCBqdXN0IGNsYXJpZnlpbmcgbXkN
Cj4gdW5kZXJzdGFuZGluZyBvZiB0aGUgY3VycmVudCBjb2RlLg0KPiANCj4gDQo+ID4NCj4gPiA+
DQo+ID4gPiA+ID4gPiArCWNhc2UgU1BSTl9EQkNSMjoNCj4gPiA+ID4gPiA+ICsJCS8qDQo+ID4g
PiA+ID4gPiArCQkgKiBJZiB1c2Vyc3BhY2UgaXMgZGVidWdnaW5nIGd1ZXN0IHRoZW4gZ3Vlc3QN
Cj4gPiA+ID4gPiA+ICsJCSAqIGNhbiBub3QgYWNjZXNzIGRlYnVnIHJlZ2lzdGVycy4NCj4gPiA+
ID4gPiA+ICsJCSAqLw0KPiA+ID4gPiA+ID4gKwkJaWYgKHZjcHUtPmd1ZXN0X2RlYnVnKQ0KPiA+
ID4gPiA+ID4gKwkJCWJyZWFrOw0KPiA+ID4gPiA+ID4gKw0KPiA+ID4gPiA+ID4gKwkJZGVidWdf
aW5zdCA9IHRydWU7DQo+ID4gPiA+ID4gPiArCQl2Y3B1LT5hcmNoLmRiZ19yZWcuZGJjcjIgPSBz
cHJfdmFsOw0KPiA+ID4gPiA+ID4gKwkJdmNwdS0+YXJjaC5zaGFkb3dfZGJnX3JlZy5kYmNyMiA9
IHNwcl92YWw7DQo+ID4gPiA+ID4gPiAgCQlicmVhazsNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IElu
IHdoYXQgY2lyY3Vtc3RhbmNlcyBjYW4gdGhlIGFyY2hpdGVjdGVkIGFuZCBzaGFkb3cgcmVnaXN0
ZXJzIGRpZmZlcj8NCj4gPiA+ID4NCj4gPiA+ID4gQXMgb2Ygbm93IHRoZXkgYXJlIHNhbWUuIEJ1
dCBJIHRoaW5rIHRoYXQgaWYgd2Ugd2FudCB0byBpbXBsZW1lbnQgb3RoZXINCj4gPiA+IGZlYXR1
cmVzIGxpa2UgIkZyZWV6ZSBUaW1lciAoRlQpIiB0aGVuIHRoZXkgY2FuIGJlIGRpZmZlcmVudC4N
Cj4gPiA+DQo+ID4gPiBJIGRvbid0IHRoaW5rIHdlIGNhbiBwb3NzaWJseSBpbXBsZW1lbnQgRnJl
ZXplIFRpbWVyLg0KPiA+DQo+ID4gTWF5IGJlLCBidXQgaW4gbXkgb3BpbmlvbiB3ZSBzaG91bGQg
a2VlcCB0aGlzIG9wZW4uDQo+IA0KPiBXZSdyZSBub3QgdGFsa2luZyBhYm91dCBBUEkgaGVyZSAt
LSB0aGUgaW1wbGVtZW50YXRpb24gc2hvdWxkIGJlIGtlcHQNCj4gc2ltcGxlIGlmIHRoZXJlJ3Mg
bm8gaW1taW5lbnQgbmVlZCBmb3Igc2hhZG93IHJlZ2lzdGVycy4NCj4gDQo+ID4gPiA+IEkgYW0g
bm90IHN1cmUgd2hhdCB3ZSBzaG91bGQgaW4gdGhhdCBjYXNlID8NCj4gPiA+ID4NCj4gPiA+ID4g
QXMgd2UgYXJlIGN1cnJlbnRseSBlbXVsYXRpbmcgYSBzdWJzZXQgb2YgZGVidWcgZXZlbnRzIChJ
QUMsIERBQywgSUMsDQo+ID4gPiA+IEJUIGFuZCBUSUUgLS0tIERCQ1IwIGVtdWxhdGlvbikgdGhl
biB3ZSBzaG91bGQgZXhwb3NlIHN0YXR1cyBvZiB0aG9zZQ0KPiA+ID4gPiBldmVudHMgaW4gZ3Vl
c3QgZGJzciBhbmQgcmVzdCBzaG91bGQgYmUgY2xlYXJlZCA/DQo+ID4gPg0KPiA+ID4gSSdtIG5v
dCBzYXlpbmcgdGhleSBuZWVkIHRvIGJlIGV4cG9zZWQgdG8gdGhlIGd1ZXN0LCBidXQgSSBkb24n
dCBzZWUgd2hlcmUNCj4geW91DQo+ID4gPiBmaWx0ZXIgb3V0IGJpdHMgbGlrZSB0aGVzZS4NCj4g
Pg0KPiA+IEkgYW0gdHJ5aW5nIHRvIGdldCB3aGF0IGFsbCBiaXRzIHNob3VsZCBiZSBmaWx0ZXJl
ZCBvdXQsIGFsbCBiaXRzDQo+ID4gZXhjZXB0IElBQ3gsIERBQ3gsIElDLCBCVCBhbmQgVElFIChz
YW1lIGFzIGV2ZW50IHNldCBmaWx0ZXJpbmcgZG9uZQ0KPiA+IHdoZW4gc2V0dGluZyBEQkNSMCkg
Pw0KPiA+DQo+ID4gaS5lIElERSwgVURFLCBNUlIsIElSUFQsIFJFVCwgQ0lSUFQsIENSRVQgc2hv
dWxkIGJlIGZpbHRlcmVkIG91dD8NCj4gDQo+IEJpdHMgbGlrZSBJUlBUIGFuZCBSRVQgZG9uJ3Qg
cmVhbGx5IG1hdHRlciwgYXMgeW91IHNob3VsZG4ndCBzZWUgdGhlbQ0KPiBoYXBwZW4uICBMaWtl
d2lzZSBNUlIgaWYgeW91J3JlIHN1cmUgeW91J3ZlIGNsZWFyZWQgaXQgc2luY2UgYm9vdC4NCg0K
V2UgY2FuIGNsZWFyIE1SUiBiaXRzIHdoZW4gdXBkYXRlIHZjcHUtPmFyY2gtPmRic3Igd2l0aCBT
UFJNX0RCU1IgaW4ga3ZtIGRlYnVnIGhhbmRsZXINCg0KPiAgQnV0DQo+IElERSBjb3VsZCBiZSBz
ZXQgYW55IHRpbWUgYW4gYXN5bmNocm9ub3VzIGV4Y2VwdGlvbiBoYXBwZW5zLiAgSSBkb24ndA0K
PiB0aGluayB5b3Ugc2hvdWxkIGZpbHRlciBpdCBvdXQsIGJ1dCBpbnN0ZWFkIG1ha2Ugc3VyZSB0
aGF0IGl0IGRvZXNuJ3QNCj4gY2F1c2UgYW4gZXhjZXB0aW9uIHRvIGJlIGRlbGl2ZXJlZC4NCg0K
U28gdGhpcyBtZWFucyB0aGF0IGluIGt2bXBwX2hhbmRsZV9kZWJ1ZygpIGlmIERCU1JfSURFIGlz
IHNldCB0aGVuIGRvIG5vdCBpbmplY3QgZGVidWcgaW50ZXJydXB0IA0KDQogYW5kDQoNCm9uIGRi
c3Igd3JpdGUgZW11bGF0aW9uLCBkZXF1ZSB0aGUgZGVidWcgaW50ZXJydXB0IGV2ZW4gaWYgREJT
Ul9JREUgaXMgc2V0Lg0KDQogICAgICAgIGNhc2UgU1BSTl9EQlNSOg0KDQogICAgICAgICAgICAg
ICAgdmNwdS0+YXJjaC5kYnNyICY9IH5zcHJfdmFsOw0KICAgICAgICAgICAgICAgIGlmICghKHZj
cHUtPmFyY2guZGJzciAmIH5EQlNSX0lERSkpDQogICAgICAgICAgICAgICAgICAgICAgICBrdm1w
cGNfY29yZV9kZXF1ZXVlX2RlYnVnKHZjcHUpOw0KICAgICAgICAgICAgICAgIGJyZWFrOw0KDQpv
cg0KICAgICAgICAgICAgICAgIHZjcHUtPmFyY2guZGJzciAmPSB+KHNwcl92YWwgfCBEQlNSX0lE
RSk7DQogICAgICAgICAgICAgICAgaWYgKCF2Y3B1LT5hcmNoLmRic3IpDQogICAgICAgICAgICAg
ICAgICAgICAgICBrdm1wcGNfY29yZV9kZXF1ZXVlX2RlYnVnKHZjcHUpOw0KICAgICAgICAgICAg
ICAgIGJyZWFrOw0KDQpUaGFua3MNCi1CaGFyYXQNCg0KPiANCj4gLVNjb3R0DQo+IA0KDQo

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Fri, 2014-08-01 at 04:34 -0500, Bhushan Bharat-R65777 wrote:
> on dbsr write emulation, deque the debug interrupt even if DBSR_IDE is set.
> 
>         case SPRN_DBSR:
> 
>                 vcpu->arch.dbsr &= ~spr_val;
>                 if (!(vcpu->arch.dbsr & ~DBSR_IDE))
>                         kvmppc_core_dequeue_debug(vcpu);
>                 break;
> 
> or
>                 vcpu->arch.dbsr &= ~(spr_val | DBSR_IDE);
>                 if (!vcpu->arch.dbsr)
>                         kvmppc_core_dequeue_debug(vcpu);
>                 break;

The first option.  I see no reason to have KVM forcibly clear DBSR[IDE].

-Scott

Re: [PATCH 6/6] KVM: PPC: BOOKE: Emulate debug registers and exception

[Scott Wood]

On Fri, 2014-08-01 at 04:34 -0500, Bhushan Bharat-R65777 wrote:
> on dbsr write emulation, deque the debug interrupt even if DBSR_IDE is set.
> 
>         case SPRN_DBSR:
> 
>                 vcpu->arch.dbsr &= ~spr_val;
>                 if (!(vcpu->arch.dbsr & ~DBSR_IDE))
>                         kvmppc_core_dequeue_debug(vcpu);
>                 break;
> 
> or
>                 vcpu->arch.dbsr &= ~(spr_val | DBSR_IDE);
>                 if (!vcpu->arch.dbsr)
>                         kvmppc_core_dequeue_debug(vcpu);
>                 break;

The first option.  I see no reason to have KVM forcibly clear DBSR[IDE].

-Scott