[PATCH 0/2] KVM: powerpc/booke: Debug interrupt injection to guest

[PATCH 0/2] KVM: powerpc/booke: Debug interrupt injection to guest

[Bharat Bhushan]

First patch add support for debug interrupt at "debug level"
while second patch add supports for allowing userspace to inject
debug interrupt to guest.

Bharat Bhushan (2):
  KVM: powerpc/booke: allow debug interrupt at "debug level"
  KVM : powerpc/booke: Allow debug interrupt injection to guest

 arch/powerpc/kvm/booke.c  | 37 ++++++++++++++++++++++++++++++++++---
 arch/powerpc/kvm/e500mc.c | 10 +++++++++-
 2 files changed, 43 insertions(+), 4 deletions(-)

-- 
1.9.0

[PATCH 1/2] KVM: powerpc/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 ab62109..bb25937 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.0

[PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat Bhushan]

This patch allow userspace to inject debug interrupt to guest.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/kvm/booke.c  | 31 +++++++++++++++++++++++++++++--
 arch/powerpc/kvm/e500mc.c | 10 +++++++++-
 2 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index bb25937..63ac38c 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -135,6 +135,11 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu *vcpu)
 #endif
 }
 
+static int kvmppc_core_pending_debug(struct kvm_vcpu *vcpu)
+{
+	return test_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
+}
+
 static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)
 {
 	/* Synchronize guest's desire to get debug interrupts into shadow MSR */
@@ -143,8 +148,11 @@ static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)
 	vcpu->arch.shadow_msr |= vcpu->arch.shared->msr & MSR_DE;
 #endif
 
-	/* Force enable debug interrupts when user space wants to debug */
-	if (vcpu->guest_debug) {
+	/*
+	 * Force enable debug interrupts when user space wants to debug
+	 * and there is no debug interrupt pending for guest to handle.
+	 */
+	if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
 #ifdef CONFIG_KVM_BOOKE_HV
 		/*
 		 * Since there is no shadow MSR, sync MSR_DE into the guest
@@ -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu *vcpu)
 	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
 }
 
+static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu)
+{
+	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG);
+}
+
+static 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
@@ -1332,6 +1350,7 @@ static void get_sregs_base(struct kvm_vcpu *vcpu,
 	sregs->u.e.dec = kvmppc_get_dec(vcpu, tb);
 	sregs->u.e.tb = tb;
 	sregs->u.e.vrsave = vcpu->arch.vrsave;
+	sregs->u.e.dbsr = vcpu->arch.dbsr;
 }
 
 static int set_sregs_base(struct kvm_vcpu *vcpu,
@@ -1356,6 +1375,14 @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
 	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
 		kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
 
+	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
+		vcpu->arch.dbsr = sregs->u.e.dbsr;
+		if (vcpu->arch.dbsr)
+			kvmppc_core_queue_debug(vcpu);
+		else
+			kvmppc_core_dequeue_debug(vcpu);
+	}
+
 	return 0;
 }
 
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 17e4562..ea724f2 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -212,7 +212,7 @@ static int kvmppc_core_get_sregs_e500mc(struct kvm_vcpu *vcpu,
 	struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
 
 	sregs->u.e.features |= KVM_SREGS_E_ARCH206_MMU | KVM_SREGS_E_PM |
-			       KVM_SREGS_E_PC;
+			       KVM_SREGS_E_PC | KVM_SREGS_E_ED;
 	sregs->u.e.impl_id = KVM_SREGS_E_IMPL_FSL;
 
 	sregs->u.e.impl.fsl.features = 0;
@@ -220,6 +220,9 @@ static int kvmppc_core_get_sregs_e500mc(struct kvm_vcpu *vcpu,
 	sregs->u.e.impl.fsl.hid0 = vcpu_e500->hid0;
 	sregs->u.e.impl.fsl.mcar = vcpu_e500->mcar;
 
+	sregs->u.e.dsrr0 = vcpu->arch.dsrr0;
+	sregs->u.e.dsrr1 = vcpu->arch.dsrr1;
+
 	kvmppc_get_sregs_e500_tlb(vcpu, sregs);
 
 	sregs->u.e.ivor_high[3] =
@@ -261,6 +264,11 @@ static int kvmppc_core_set_sregs_e500mc(struct kvm_vcpu *vcpu,
 			sregs->u.e.ivor_high[5];
 	}
 
+	if (sregs->u.e.features & KVM_SREGS_E_ED) {
+		vcpu->arch.dsrr0 = sregs->u.e.dsrr0;
+		vcpu->arch.dsrr1 = sregs->u.e.dsrr1;
+	}
+
 	return kvmppc_set_sregs_ivor(vcpu, sregs);
 }
 
-- 
1.9.0

[PATCH 0/2] KVM: powerpc/booke: Debug interrupt injection to guest

[Bharat Bhushan]

First patch add support for debug interrupt at "debug level"
while second patch add supports for allowing userspace to inject
debug interrupt to guest.

Bharat Bhushan (2):
  KVM: powerpc/booke: allow debug interrupt at "debug level"
  KVM : powerpc/booke: Allow debug interrupt injection to guest

 arch/powerpc/kvm/booke.c  | 37 ++++++++++++++++++++++++++++++++++---
 arch/powerpc/kvm/e500mc.c | 10 +++++++++-
 2 files changed, 43 insertions(+), 4 deletions(-)

-- 
1.9.0

[PATCH 1/2] KVM: powerpc/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 ab62109..bb25937 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.0

[PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat Bhushan]

This patch allow userspace to inject debug interrupt to guest.

Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
---
 arch/powerpc/kvm/booke.c  | 31 +++++++++++++++++++++++++++++--
 arch/powerpc/kvm/e500mc.c | 10 +++++++++-
 2 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index bb25937..63ac38c 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -135,6 +135,11 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu *vcpu)
 #endif
 }
 
+static int kvmppc_core_pending_debug(struct kvm_vcpu *vcpu)
+{
+	return test_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
+}
+
 static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)
 {
 	/* Synchronize guest's desire to get debug interrupts into shadow MSR */
@@ -143,8 +148,11 @@ static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)
 	vcpu->arch.shadow_msr |= vcpu->arch.shared->msr & MSR_DE;
 #endif
 
-	/* Force enable debug interrupts when user space wants to debug */
-	if (vcpu->guest_debug) {
+	/*
+	 * Force enable debug interrupts when user space wants to debug
+	 * and there is no debug interrupt pending for guest to handle.
+	 */
+	if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
 #ifdef CONFIG_KVM_BOOKE_HV
 		/*
 		 * Since there is no shadow MSR, sync MSR_DE into the guest
@@ -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu *vcpu)
 	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
 }
 
+static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu)
+{
+	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG);
+}
+
+static 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
@@ -1332,6 +1350,7 @@ static void get_sregs_base(struct kvm_vcpu *vcpu,
 	sregs->u.e.dec = kvmppc_get_dec(vcpu, tb);
 	sregs->u.e.tb = tb;
 	sregs->u.e.vrsave = vcpu->arch.vrsave;
+	sregs->u.e.dbsr = vcpu->arch.dbsr;
 }
 
 static int set_sregs_base(struct kvm_vcpu *vcpu,
@@ -1356,6 +1375,14 @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
 	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
 		kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
 
+	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
+		vcpu->arch.dbsr = sregs->u.e.dbsr;
+		if (vcpu->arch.dbsr)
+			kvmppc_core_queue_debug(vcpu);
+		else
+			kvmppc_core_dequeue_debug(vcpu);
+	}
+
 	return 0;
 }
 
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index 17e4562..ea724f2 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -212,7 +212,7 @@ static int kvmppc_core_get_sregs_e500mc(struct kvm_vcpu *vcpu,
 	struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
 
 	sregs->u.e.features |= KVM_SREGS_E_ARCH206_MMU | KVM_SREGS_E_PM |
-			       KVM_SREGS_E_PC;
+			       KVM_SREGS_E_PC | KVM_SREGS_E_ED;
 	sregs->u.e.impl_id = KVM_SREGS_E_IMPL_FSL;
 
 	sregs->u.e.impl.fsl.features = 0;
@@ -220,6 +220,9 @@ static int kvmppc_core_get_sregs_e500mc(struct kvm_vcpu *vcpu,
 	sregs->u.e.impl.fsl.hid0 = vcpu_e500->hid0;
 	sregs->u.e.impl.fsl.mcar = vcpu_e500->mcar;
 
+	sregs->u.e.dsrr0 = vcpu->arch.dsrr0;
+	sregs->u.e.dsrr1 = vcpu->arch.dsrr1;
+
 	kvmppc_get_sregs_e500_tlb(vcpu, sregs);
 
 	sregs->u.e.ivor_high[3] @@ -261,6 +264,11 @@ static int kvmppc_core_set_sregs_e500mc(struct kvm_vcpu *vcpu,
 			sregs->u.e.ivor_high[5];
 	}
 
+	if (sregs->u.e.features & KVM_SREGS_E_ED) {
+		vcpu->arch.dsrr0 = sregs->u.e.dsrr0;
+		vcpu->arch.dsrr1 = sregs->u.e.dsrr1;
+	}
+
 	return kvmppc_set_sregs_ivor(vcpu, sregs);
 }
 
-- 
1.9.0

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Scott Wood]

On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> This patch allow userspace to inject debug interrupt to guest.
> 
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>

Could you describe how userspace plans to make use of this, and go into
more detail about the changes you're making?

> ---
>  arch/powerpc/kvm/booke.c  | 31 +++++++++++++++++++++++++++++--
>  arch/powerpc/kvm/e500mc.c | 10 +++++++++-
>  2 files changed, 38 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index bb25937..63ac38c 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -135,6 +135,11 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu *vcpu)
>  #endif
>  }
>  
> +static int kvmppc_core_pending_debug(struct kvm_vcpu *vcpu)
> +{
> +	return test_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
> +}
> +
>  static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)
>  {
>  	/* Synchronize guest's desire to get debug interrupts into shadow MSR */
> @@ -143,8 +148,11 @@ static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)
>  	vcpu->arch.shadow_msr |= vcpu->arch.shared->msr & MSR_DE;
>  #endif
>  
> -	/* Force enable debug interrupts when user space wants to debug */
> -	if (vcpu->guest_debug) {
> +	/*
> +	 * Force enable debug interrupts when user space wants to debug
> +	 * and there is no debug interrupt pending for guest to handle.
> +	 */
> +	if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {

Are you trying to allow the guest to be simultaneously debugged by
itself and by host userspace?  How does this work?

>  #ifdef CONFIG_KVM_BOOKE_HV
>  		/*
>  		 * Since there is no shadow MSR, sync MSR_DE into the guest
> @@ -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu *vcpu)
>  	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
>  }
>  
> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu)
> +{
> +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG);
> +}
> +
> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu)
> +{
> +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
> +}

Is there currently no support for a guest debugging itself (i.e.
guest_debug unset) on e500v2?

>  static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0, u32 srr1)
>  {
>  #ifdef CONFIG_KVM_BOOKE_HV
> @@ -1332,6 +1350,7 @@ static void get_sregs_base(struct kvm_vcpu *vcpu,
>  	sregs->u.e.dec = kvmppc_get_dec(vcpu, tb);
>  	sregs->u.e.tb = tb;
>  	sregs->u.e.vrsave = vcpu->arch.vrsave;
> +	sregs->u.e.dbsr = vcpu->arch.dbsr;
>  }
>  
>  static int set_sregs_base(struct kvm_vcpu *vcpu,
> @@ -1356,6 +1375,14 @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
>  	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
>  		kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
>  
> +	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
> +		vcpu->arch.dbsr = sregs->u.e.dbsr;
> +		if (vcpu->arch.dbsr)
> +			kvmppc_core_queue_debug(vcpu);
> +		else
> +			kvmppc_core_dequeue_debug(vcpu);
> +	}
> +
>  	return 0;
>  }

one reg?
 
> diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
> index 17e4562..ea724f2 100644
> --- a/arch/powerpc/kvm/e500mc.c
> +++ b/arch/powerpc/kvm/e500mc.c
> @@ -212,7 +212,7 @@ static int kvmppc_core_get_sregs_e500mc(struct kvm_vcpu *vcpu,
>  	struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
>  
>  	sregs->u.e.features |= KVM_SREGS_E_ARCH206_MMU | KVM_SREGS_E_PM |
> -			       KVM_SREGS_E_PC;
> +			       KVM_SREGS_E_PC | KVM_SREGS_E_ED;
>
>  	sregs->u.e.impl_id = KVM_SREGS_E_IMPL_FSL;
>  
>  	sregs->u.e.impl.fsl.features = 0;
> @@ -220,6 +220,9 @@ static int kvmppc_core_get_sregs_e500mc(struct kvm_vcpu *vcpu,
>  	sregs->u.e.impl.fsl.hid0 = vcpu_e500->hid0;
>  	sregs->u.e.impl.fsl.mcar = vcpu_e500->mcar;
>  
> +	sregs->u.e.dsrr0 = vcpu->arch.dsrr0;
> +	sregs->u.e.dsrr1 = vcpu->arch.dsrr1;
> +
>  	kvmppc_get_sregs_e500_tlb(vcpu, sregs);
>  
>  	sregs->u.e.ivor_high[3] =
> @@ -261,6 +264,11 @@ static int kvmppc_core_set_sregs_e500mc(struct kvm_vcpu *vcpu,
>  			sregs->u.e.ivor_high[5];
>  	}
>  
> +	if (sregs->u.e.features & KVM_SREGS_E_ED) {
> +		vcpu->arch.dsrr0 = sregs->u.e.dsrr0;
> +		vcpu->arch.dsrr1 = sregs->u.e.dsrr1;
> +	}

SPRG9?

-Scott

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Scott Wood]

On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> This patch allow userspace to inject debug interrupt to guest.
> 
> Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>

Could you describe how userspace plans to make use of this, and go into
more detail about the changes you're making?

> ---
>  arch/powerpc/kvm/booke.c  | 31 +++++++++++++++++++++++++++++--
>  arch/powerpc/kvm/e500mc.c | 10 +++++++++-
>  2 files changed, 38 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> index bb25937..63ac38c 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -135,6 +135,11 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu *vcpu)
>  #endif
>  }
>  
> +static int kvmppc_core_pending_debug(struct kvm_vcpu *vcpu)
> +{
> +	return test_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
> +}
> +
>  static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)
>  {
>  	/* Synchronize guest's desire to get debug interrupts into shadow MSR */
> @@ -143,8 +148,11 @@ static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)
>  	vcpu->arch.shadow_msr |= vcpu->arch.shared->msr & MSR_DE;
>  #endif
>  
> -	/* Force enable debug interrupts when user space wants to debug */
> -	if (vcpu->guest_debug) {
> +	/*
> +	 * Force enable debug interrupts when user space wants to debug
> +	 * and there is no debug interrupt pending for guest to handle.
> +	 */
> +	if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {

Are you trying to allow the guest to be simultaneously debugged by
itself and by host userspace?  How does this work?

>  #ifdef CONFIG_KVM_BOOKE_HV
>  		/*
>  		 * Since there is no shadow MSR, sync MSR_DE into the guest
> @@ -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu *vcpu)
>  	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
>  }
>  
> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu)
> +{
> +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG);
> +}
> +
> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu)
> +{
> +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
> +}

Is there currently no support for a guest debugging itself (i.e.
guest_debug unset) on e500v2?

>  static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0, u32 srr1)
>  {
>  #ifdef CONFIG_KVM_BOOKE_HV
> @@ -1332,6 +1350,7 @@ static void get_sregs_base(struct kvm_vcpu *vcpu,
>  	sregs->u.e.dec = kvmppc_get_dec(vcpu, tb);
>  	sregs->u.e.tb = tb;
>  	sregs->u.e.vrsave = vcpu->arch.vrsave;
> +	sregs->u.e.dbsr = vcpu->arch.dbsr;
>  }
>  
>  static int set_sregs_base(struct kvm_vcpu *vcpu,
> @@ -1356,6 +1375,14 @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
>  	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
>  		kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
>  
> +	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
> +		vcpu->arch.dbsr = sregs->u.e.dbsr;
> +		if (vcpu->arch.dbsr)
> +			kvmppc_core_queue_debug(vcpu);
> +		else
> +			kvmppc_core_dequeue_debug(vcpu);
> +	}
> +
>  	return 0;
>  }

one reg?
 
> diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
> index 17e4562..ea724f2 100644
> --- a/arch/powerpc/kvm/e500mc.c
> +++ b/arch/powerpc/kvm/e500mc.c
> @@ -212,7 +212,7 @@ static int kvmppc_core_get_sregs_e500mc(struct kvm_vcpu *vcpu,
>  	struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
>  
>  	sregs->u.e.features |= KVM_SREGS_E_ARCH206_MMU | KVM_SREGS_E_PM |
> -			       KVM_SREGS_E_PC;
> +			       KVM_SREGS_E_PC | KVM_SREGS_E_ED;
>
>  	sregs->u.e.impl_id = KVM_SREGS_E_IMPL_FSL;
>  
>  	sregs->u.e.impl.fsl.features = 0;
> @@ -220,6 +220,9 @@ static int kvmppc_core_get_sregs_e500mc(struct kvm_vcpu *vcpu,
>  	sregs->u.e.impl.fsl.hid0 = vcpu_e500->hid0;
>  	sregs->u.e.impl.fsl.mcar = vcpu_e500->mcar;
>  
> +	sregs->u.e.dsrr0 = vcpu->arch.dsrr0;
> +	sregs->u.e.dsrr1 = vcpu->arch.dsrr1;
> +
>  	kvmppc_get_sregs_e500_tlb(vcpu, sregs);
>  
>  	sregs->u.e.ivor_high[3] > @@ -261,6 +264,11 @@ static int kvmppc_core_set_sregs_e500mc(struct kvm_vcpu *vcpu,
>  			sregs->u.e.ivor_high[5];
>  	}
>  
> +	if (sregs->u.e.features & KVM_SREGS_E_ED) {
> +		vcpu->arch.dsrr0 = sregs->u.e.dsrr0;
> +		vcpu->arch.dsrr1 = sregs->u.e.dsrr1;
> +	}

SPRG9?

-Scott

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Friday, June 27, 2014 11:53 PM
> To: Bhushan Bharat-R65777
> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> guest
> 
> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> > This patch allow userspace to inject debug interrupt to guest.
> >
> > Signed-off-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
> 
> Could you describe how userspace plans to make use of this, and go into more
> detail about the changes you're making?

When a debug interrupt happens in guest then we switch to host userspace (QEMU) and if QEMU is not able to handle a debug interrupt then it injects the debug interrupt to guest. QEMU uses SET_SREGS (not a one_reg interface), with DBSR have proper values, for injecting the debug interrupt. In SET_SREGS handling for DBSR register, KVM injects debug interrupt to guest.

> 
> > ---
> >  arch/powerpc/kvm/booke.c  | 31 +++++++++++++++++++++++++++++--
> > arch/powerpc/kvm/e500mc.c | 10 +++++++++-
> >  2 files changed, 38 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c index
> > bb25937..63ac38c 100644
> > --- a/arch/powerpc/kvm/booke.c
> > +++ b/arch/powerpc/kvm/booke.c
> > @@ -135,6 +135,11 @@ static void kvmppc_vcpu_sync_fpu(struct kvm_vcpu
> > *vcpu)  #endif  }
> >
> > +static int kvmppc_core_pending_debug(struct kvm_vcpu *vcpu) {
> > +	return test_bit(BOOKE_IRQPRIO_DEBUG,
> > +&vcpu->arch.pending_exceptions); }
> > +
> >  static void kvmppc_vcpu_sync_debug(struct kvm_vcpu *vcpu)  {
> >  	/* Synchronize guest's desire to get debug interrupts into shadow
> > MSR */ @@ -143,8 +148,11 @@ static void kvmppc_vcpu_sync_debug(struct kvm_vcpu
> *vcpu)
> >  	vcpu->arch.shadow_msr |= vcpu->arch.shared->msr & MSR_DE;  #endif
> >
> > -	/* Force enable debug interrupts when user space wants to debug */
> > -	if (vcpu->guest_debug) {
> > +	/*
> > +	 * Force enable debug interrupts when user space wants to debug
> > +	 * and there is no debug interrupt pending for guest to handle.
> > +	 */
> > +	if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
> 
> Are you trying to allow the guest to be simultaneously debugged by itself and by
> host userspace?  How does this work?

Not actually, Currently we are not partitioning debug resources between host userspace and guest. In fact we do not emulate debug registers for guest. But we want host userspace to pass the interrupt to guest if it is not able to handle. 

> 
> >  #ifdef CONFIG_KVM_BOOKE_HV
> >  		/*
> >  		 * Since there is no shadow MSR, sync MSR_DE into the guest @@
> > -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu
> *vcpu)
> >  	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
> > }
> >
> > +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
> > +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
> > +
> > +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
> > +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions); }
> 
> Is there currently no support for a guest debugging itself (i.e.
> guest_debug unset) on e500v2?

Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet emulated). 

> 
> >  static void set_guest_srr(struct kvm_vcpu *vcpu, unsigned long srr0,
> > u32 srr1)  {  #ifdef CONFIG_KVM_BOOKE_HV @@ -1332,6 +1350,7 @@ static
> > void get_sregs_base(struct kvm_vcpu *vcpu,
> >  	sregs->u.e.dec = kvmppc_get_dec(vcpu, tb);
> >  	sregs->u.e.tb = tb;
> >  	sregs->u.e.vrsave = vcpu->arch.vrsave;
> > +	sregs->u.e.dbsr = vcpu->arch.dbsr;
> >  }
> >
> >  static int set_sregs_base(struct kvm_vcpu *vcpu, @@ -1356,6 +1375,14
> > @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
> >  	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
> >  		kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
> >
> > +	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
> > +		vcpu->arch.dbsr = sregs->u.e.dbsr;
> > +		if (vcpu->arch.dbsr)
> > +			kvmppc_core_queue_debug(vcpu);
> > +		else
> > +			kvmppc_core_dequeue_debug(vcpu);
> > +	}
> > +
> >  	return 0;
> >  }
> 
> one reg?

We are using SREGS but if required we can use one_reg.

> 
> > diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
> > index 17e4562..ea724f2 100644
> > --- a/arch/powerpc/kvm/e500mc.c
> > +++ b/arch/powerpc/kvm/e500mc.c
> > @@ -212,7 +212,7 @@ static int kvmppc_core_get_sregs_e500mc(struct kvm_vcpu
> *vcpu,
> >  	struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
> >
> >  	sregs->u.e.features |= KVM_SREGS_E_ARCH206_MMU | KVM_SREGS_E_PM |
> > -			       KVM_SREGS_E_PC;
> > +			       KVM_SREGS_E_PC | KVM_SREGS_E_ED;
> >
> >  	sregs->u.e.impl_id = KVM_SREGS_E_IMPL_FSL;
> >
> >  	sregs->u.e.impl.fsl.features = 0;
> > @@ -220,6 +220,9 @@ static int kvmppc_core_get_sregs_e500mc(struct kvm_vcpu
> *vcpu,
> >  	sregs->u.e.impl.fsl.hid0 = vcpu_e500->hid0;
> >  	sregs->u.e.impl.fsl.mcar = vcpu_e500->mcar;
> >
> > +	sregs->u.e.dsrr0 = vcpu->arch.dsrr0;
> > +	sregs->u.e.dsrr1 = vcpu->arch.dsrr1;
> > +
> >  	kvmppc_get_sregs_e500_tlb(vcpu, sregs);
> >
> >  	sregs->u.e.ivor_high[3] =
> > @@ -261,6 +264,11 @@ static int kvmppc_core_set_sregs_e500mc(struct kvm_vcpu
> *vcpu,
> >  			sregs->u.e.ivor_high[5];
> >  	}
> >
> > +	if (sregs->u.e.features & KVM_SREGS_E_ED) {
> > +		vcpu->arch.dsrr0 = sregs->u.e.dsrr0;
> > +		vcpu->arch.dsrr1 = sregs->u.e.dsrr1;
> > +	}
> 
> SPRG9?

Yes we need to emulate this register as well, and other DEBUG registers.
So the question is, should this patch be sent with the patchset when we emulates other debug registers for guest?

> 
> -Scott
> 

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogRnJpZGF5LCBKdW5lIDI3LCAyMDE0IDExOjUzIFBNDQo+IFRvOiBCaHVzaGFu
IEJoYXJhdC1SNjU3NzcNCj4gQ2M6IGFncmFmQHN1c2UuZGU7IGt2bS1wcGNAdmdlci5rZXJuZWwu
b3JnOyBrdm1Admdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8yXSBLVk0g
OiBwb3dlcnBjL2Jvb2tlOiBBbGxvdyBkZWJ1ZyBpbnRlcnJ1cHQgaW5qZWN0aW9uIHRvDQo+IGd1
ZXN0DQo+IA0KPiBPbiBGcmksIDIwMTQtMDYtMjcgYXQgMTE6NTUgKzA1MzAsIEJoYXJhdCBCaHVz
aGFuIHdyb3RlOg0KPiA+IFRoaXMgcGF0Y2ggYWxsb3cgdXNlcnNwYWNlIHRvIGluamVjdCBkZWJ1
ZyBpbnRlcnJ1cHQgdG8gZ3Vlc3QuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBCaGFyYXQgQmh1
c2hhbiA8QmhhcmF0LkJodXNoYW5AZnJlZXNjYWxlLmNvbT4NCj4gDQo+IENvdWxkIHlvdSBkZXNj
cmliZSBob3cgdXNlcnNwYWNlIHBsYW5zIHRvIG1ha2UgdXNlIG9mIHRoaXMsIGFuZCBnbyBpbnRv
IG1vcmUNCj4gZGV0YWlsIGFib3V0IHRoZSBjaGFuZ2VzIHlvdSdyZSBtYWtpbmc/DQoNCldoZW4g
YSBkZWJ1ZyBpbnRlcnJ1cHQgaGFwcGVucyBpbiBndWVzdCB0aGVuIHdlIHN3aXRjaCB0byBob3N0
IHVzZXJzcGFjZSAoUUVNVSkgYW5kIGlmIFFFTVUgaXMgbm90IGFibGUgdG8gaGFuZGxlIGEgZGVi
dWcgaW50ZXJydXB0IHRoZW4gaXQgaW5qZWN0cyB0aGUgZGVidWcgaW50ZXJydXB0IHRvIGd1ZXN0
LiBRRU1VIHVzZXMgU0VUX1NSRUdTIChub3QgYSBvbmVfcmVnIGludGVyZmFjZSksIHdpdGggREJT
UiBoYXZlIHByb3BlciB2YWx1ZXMsIGZvciBpbmplY3RpbmcgdGhlIGRlYnVnIGludGVycnVwdC4g
SW4gU0VUX1NSRUdTIGhhbmRsaW5nIGZvciBEQlNSIHJlZ2lzdGVyLCBLVk0gaW5qZWN0cyBkZWJ1
ZyBpbnRlcnJ1cHQgdG8gZ3Vlc3QuDQoNCj4gDQo+ID4gLS0tDQo+ID4gIGFyY2gvcG93ZXJwYy9r
dm0vYm9va2UuYyAgfCAzMSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tDQo+ID4gYXJj
aC9wb3dlcnBjL2t2bS9lNTAwbWMuYyB8IDEwICsrKysrKysrKy0NCj4gPiAgMiBmaWxlcyBjaGFu
Z2VkLCAzOCBpbnNlcnRpb25zKCspLCAzIGRlbGV0aW9ucygtKQ0KPiA+DQo+ID4gZGlmZiAtLWdp
dCBhL2FyY2gvcG93ZXJwYy9rdm0vYm9va2UuYyBiL2FyY2gvcG93ZXJwYy9rdm0vYm9va2UuYyBp
bmRleA0KPiA+IGJiMjU5MzcuLjYzYWMzOGMgMTAwNjQ0DQo+ID4gLS0tIGEvYXJjaC9wb3dlcnBj
L2t2bS9ib29rZS5jDQo+ID4gKysrIGIvYXJjaC9wb3dlcnBjL2t2bS9ib29rZS5jDQo+ID4gQEAg
LTEzNSw2ICsxMzUsMTEgQEAgc3RhdGljIHZvaWQga3ZtcHBjX3ZjcHVfc3luY19mcHUoc3RydWN0
IGt2bV92Y3B1DQo+ID4gKnZjcHUpICAjZW5kaWYgIH0NCj4gPg0KPiA+ICtzdGF0aWMgaW50IGt2
bXBwY19jb3JlX3BlbmRpbmdfZGVidWcoc3RydWN0IGt2bV92Y3B1ICp2Y3B1KSB7DQo+ID4gKwly
ZXR1cm4gdGVzdF9iaXQoQk9PS0VfSVJRUFJJT19ERUJVRywNCj4gPiArJnZjcHUtPmFyY2gucGVu
ZGluZ19leGNlcHRpb25zKTsgfQ0KPiA+ICsNCj4gPiAgc3RhdGljIHZvaWQga3ZtcHBjX3ZjcHVf
c3luY19kZWJ1ZyhzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUpICB7DQo+ID4gIAkvKiBTeW5jaHJvbml6
ZSBndWVzdCdzIGRlc2lyZSB0byBnZXQgZGVidWcgaW50ZXJydXB0cyBpbnRvIHNoYWRvdw0KPiA+
IE1TUiAqLyBAQCAtMTQzLDggKzE0OCwxMSBAQCBzdGF0aWMgdm9pZCBrdm1wcGNfdmNwdV9zeW5j
X2RlYnVnKHN0cnVjdCBrdm1fdmNwdQ0KPiAqdmNwdSkNCj4gPiAgCXZjcHUtPmFyY2guc2hhZG93
X21zciB8PSB2Y3B1LT5hcmNoLnNoYXJlZC0+bXNyICYgTVNSX0RFOyAgI2VuZGlmDQo+ID4NCj4g
PiAtCS8qIEZvcmNlIGVuYWJsZSBkZWJ1ZyBpbnRlcnJ1cHRzIHdoZW4gdXNlciBzcGFjZSB3YW50
cyB0byBkZWJ1ZyAqLw0KPiA+IC0JaWYgKHZjcHUtPmd1ZXN0X2RlYnVnKSB7DQo+ID4gKwkvKg0K
PiA+ICsJICogRm9yY2UgZW5hYmxlIGRlYnVnIGludGVycnVwdHMgd2hlbiB1c2VyIHNwYWNlIHdh
bnRzIHRvIGRlYnVnDQo+ID4gKwkgKiBhbmQgdGhlcmUgaXMgbm8gZGVidWcgaW50ZXJydXB0IHBl
bmRpbmcgZm9yIGd1ZXN0IHRvIGhhbmRsZS4NCj4gPiArCSAqLw0KPiA+ICsJaWYgKHZjcHUtPmd1
ZXN0X2RlYnVnICYmICFrdm1wcGNfY29yZV9wZW5kaW5nX2RlYnVnKHZjcHUpKSB7DQo+IA0KPiBB
cmUgeW91IHRyeWluZyB0byBhbGxvdyB0aGUgZ3Vlc3QgdG8gYmUgc2ltdWx0YW5lb3VzbHkgZGVi
dWdnZWQgYnkgaXRzZWxmIGFuZCBieQ0KPiBob3N0IHVzZXJzcGFjZT8gIEhvdyBkb2VzIHRoaXMg
d29yaz8NCg0KTm90IGFjdHVhbGx5LCBDdXJyZW50bHkgd2UgYXJlIG5vdCBwYXJ0aXRpb25pbmcg
ZGVidWcgcmVzb3VyY2VzIGJldHdlZW4gaG9zdCB1c2Vyc3BhY2UgYW5kIGd1ZXN0LiBJbiBmYWN0
IHdlIGRvIG5vdCBlbXVsYXRlIGRlYnVnIHJlZ2lzdGVycyBmb3IgZ3Vlc3QuIEJ1dCB3ZSB3YW50
IGhvc3QgdXNlcnNwYWNlIHRvIHBhc3MgdGhlIGludGVycnVwdCB0byBndWVzdCBpZiBpdCBpcyBu
b3QgYWJsZSB0byBoYW5kbGUuIA0KDQo+IA0KPiA+ICAjaWZkZWYgQ09ORklHX0tWTV9CT09LRV9I
Vg0KPiA+ICAJCS8qDQo+ID4gIAkJICogU2luY2UgdGhlcmUgaXMgbm8gc2hhZG93IE1TUiwgc3lu
YyBNU1JfREUgaW50byB0aGUgZ3Vlc3QgQEANCj4gPiAtMjY0LDYgKzI3MiwxNiBAQCBzdGF0aWMg
dm9pZCBrdm1wcGNfY29yZV9kZXF1ZXVlX3dhdGNoZG9nKHN0cnVjdCBrdm1fdmNwdQ0KPiAqdmNw
dSkNCj4gPiAgCWNsZWFyX2JpdChCT09LRV9JUlFQUklPX1dBVENIRE9HLCAmdmNwdS0+YXJjaC5w
ZW5kaW5nX2V4Y2VwdGlvbnMpOw0KPiA+IH0NCj4gPg0KPiA+ICtzdGF0aWMgdm9pZCBrdm1wcGNf
Y29yZV9xdWV1ZV9kZWJ1ZyhzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUpIHsNCj4gPiArCWt2bXBwY19i
b29rZV9xdWV1ZV9pcnFwcmlvKHZjcHUsIEJPT0tFX0lSUVBSSU9fREVCVUcpOyB9DQo+ID4gKw0K
PiA+ICtzdGF0aWMgdm9pZCBrdm1wcGNfY29yZV9kZXF1ZXVlX2RlYnVnKHN0cnVjdCBrdm1fdmNw
dSAqdmNwdSkgew0KPiA+ICsJY2xlYXJfYml0KEJPT0tFX0lSUVBSSU9fREVCVUcsICZ2Y3B1LT5h
cmNoLnBlbmRpbmdfZXhjZXB0aW9ucyk7IH0NCj4gDQo+IElzIHRoZXJlIGN1cnJlbnRseSBubyBz
dXBwb3J0IGZvciBhIGd1ZXN0IGRlYnVnZ2luZyBpdHNlbGYgKGkuZS4NCj4gZ3Vlc3RfZGVidWcg
dW5zZXQpIG9uIGU1MDB2Mj8NCg0KWWVzLCBJdCBpcyBub3QgeWV0IHN1cHBvcnRlZCAoSUFDeC9E
QUN4L0RCQ1IvREJTUi9EU1JSeCBhcmUgbm90IHlldCBlbXVsYXRlZCkuIA0KDQo+IA0KPiA+ICBz
dGF0aWMgdm9pZCBzZXRfZ3Vlc3Rfc3JyKHN0cnVjdCBrdm1fdmNwdSAqdmNwdSwgdW5zaWduZWQg
bG9uZyBzcnIwLA0KPiA+IHUzMiBzcnIxKSAgeyAgI2lmZGVmIENPTkZJR19LVk1fQk9PS0VfSFYg
QEAgLTEzMzIsNiArMTM1MCw3IEBAIHN0YXRpYw0KPiA+IHZvaWQgZ2V0X3NyZWdzX2Jhc2Uoc3Ry
dWN0IGt2bV92Y3B1ICp2Y3B1LA0KPiA+ICAJc3JlZ3MtPnUuZS5kZWMgPSBrdm1wcGNfZ2V0X2Rl
Yyh2Y3B1LCB0Yik7DQo+ID4gIAlzcmVncy0+dS5lLnRiID0gdGI7DQo+ID4gIAlzcmVncy0+dS5l
LnZyc2F2ZSA9IHZjcHUtPmFyY2gudnJzYXZlOw0KPiA+ICsJc3JlZ3MtPnUuZS5kYnNyID0gdmNw
dS0+YXJjaC5kYnNyOw0KPiA+ICB9DQo+ID4NCj4gPiAgc3RhdGljIGludCBzZXRfc3JlZ3NfYmFz
ZShzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUsIEBAIC0xMzU2LDYgKzEzNzUsMTQNCj4gPiBAQCBzdGF0
aWMgaW50IHNldF9zcmVnc19iYXNlKHN0cnVjdCBrdm1fdmNwdSAqdmNwdSwNCj4gPiAgCWlmIChz
cmVncy0+dS5lLnVwZGF0ZV9zcGVjaWFsICYgS1ZNX1NSRUdTX0VfVVBEQVRFX1RTUikNCj4gPiAg
CQlrdm1wcGNfc2V0X3Rzcih2Y3B1LCBzcmVncy0+dS5lLnRzcik7DQo+ID4NCj4gPiArCWlmIChz
cmVncy0+dS5lLnVwZGF0ZV9zcGVjaWFsICYgS1ZNX1NSRUdTX0VfVVBEQVRFX0RCU1IpIHsNCj4g
PiArCQl2Y3B1LT5hcmNoLmRic3IgPSBzcmVncy0+dS5lLmRic3I7DQo+ID4gKwkJaWYgKHZjcHUt
PmFyY2guZGJzcikNCj4gPiArCQkJa3ZtcHBjX2NvcmVfcXVldWVfZGVidWcodmNwdSk7DQo+ID4g
KwkJZWxzZQ0KPiA+ICsJCQlrdm1wcGNfY29yZV9kZXF1ZXVlX2RlYnVnKHZjcHUpOw0KPiA+ICsJ
fQ0KPiA+ICsNCj4gPiAgCXJldHVybiAwOw0KPiA+ICB9DQo+IA0KPiBvbmUgcmVnPw0KDQpXZSBh
cmUgdXNpbmcgU1JFR1MgYnV0IGlmIHJlcXVpcmVkIHdlIGNhbiB1c2Ugb25lX3JlZy4NCg0KPiAN
Cj4gPiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL2t2bS9lNTAwbWMuYyBiL2FyY2gvcG93ZXJw
Yy9rdm0vZTUwMG1jLmMNCj4gPiBpbmRleCAxN2U0NTYyLi5lYTcyNGYyIDEwMDY0NA0KPiA+IC0t
LSBhL2FyY2gvcG93ZXJwYy9rdm0vZTUwMG1jLmMNCj4gPiArKysgYi9hcmNoL3Bvd2VycGMva3Zt
L2U1MDBtYy5jDQo+ID4gQEAgLTIxMiw3ICsyMTIsNyBAQCBzdGF0aWMgaW50IGt2bXBwY19jb3Jl
X2dldF9zcmVnc19lNTAwbWMoc3RydWN0IGt2bV92Y3B1DQo+ICp2Y3B1LA0KPiA+ICAJc3RydWN0
IGt2bXBwY192Y3B1X2U1MDAgKnZjcHVfZTUwMCA9IHRvX2U1MDAodmNwdSk7DQo+ID4NCj4gPiAg
CXNyZWdzLT51LmUuZmVhdHVyZXMgfD0gS1ZNX1NSRUdTX0VfQVJDSDIwNl9NTVUgfCBLVk1fU1JF
R1NfRV9QTSB8DQo+ID4gLQkJCSAgICAgICBLVk1fU1JFR1NfRV9QQzsNCj4gPiArCQkJICAgICAg
IEtWTV9TUkVHU19FX1BDIHwgS1ZNX1NSRUdTX0VfRUQ7DQo+ID4NCj4gPiAgCXNyZWdzLT51LmUu
aW1wbF9pZCA9IEtWTV9TUkVHU19FX0lNUExfRlNMOw0KPiA+DQo+ID4gIAlzcmVncy0+dS5lLmlt
cGwuZnNsLmZlYXR1cmVzID0gMDsNCj4gPiBAQCAtMjIwLDYgKzIyMCw5IEBAIHN0YXRpYyBpbnQg
a3ZtcHBjX2NvcmVfZ2V0X3NyZWdzX2U1MDBtYyhzdHJ1Y3Qga3ZtX3ZjcHUNCj4gKnZjcHUsDQo+
ID4gIAlzcmVncy0+dS5lLmltcGwuZnNsLmhpZDAgPSB2Y3B1X2U1MDAtPmhpZDA7DQo+ID4gIAlz
cmVncy0+dS5lLmltcGwuZnNsLm1jYXIgPSB2Y3B1X2U1MDAtPm1jYXI7DQo+ID4NCj4gPiArCXNy
ZWdzLT51LmUuZHNycjAgPSB2Y3B1LT5hcmNoLmRzcnIwOw0KPiA+ICsJc3JlZ3MtPnUuZS5kc3Jy
MSA9IHZjcHUtPmFyY2guZHNycjE7DQo+ID4gKw0KPiA+ICAJa3ZtcHBjX2dldF9zcmVnc19lNTAw
X3RsYih2Y3B1LCBzcmVncyk7DQo+ID4NCj4gPiAgCXNyZWdzLT51LmUuaXZvcl9oaWdoWzNdID0N
Cj4gPiBAQCAtMjYxLDYgKzI2NCwxMSBAQCBzdGF0aWMgaW50IGt2bXBwY19jb3JlX3NldF9zcmVn
c19lNTAwbWMoc3RydWN0IGt2bV92Y3B1DQo+ICp2Y3B1LA0KPiA+ICAJCQlzcmVncy0+dS5lLml2
b3JfaGlnaFs1XTsNCj4gPiAgCX0NCj4gPg0KPiA+ICsJaWYgKHNyZWdzLT51LmUuZmVhdHVyZXMg
JiBLVk1fU1JFR1NfRV9FRCkgew0KPiA+ICsJCXZjcHUtPmFyY2guZHNycjAgPSBzcmVncy0+dS5l
LmRzcnIwOw0KPiA+ICsJCXZjcHUtPmFyY2guZHNycjEgPSBzcmVncy0+dS5lLmRzcnIxOw0KPiA+
ICsJfQ0KPiANCj4gU1BSRzk/DQoNClllcyB3ZSBuZWVkIHRvIGVtdWxhdGUgdGhpcyByZWdpc3Rl
ciBhcyB3ZWxsLCBhbmQgb3RoZXIgREVCVUcgcmVnaXN0ZXJzLg0KU28gdGhlIHF1ZXN0aW9uIGlz
LCBzaG91bGQgdGhpcyBwYXRjaCBiZSBzZW50IHdpdGggdGhlIHBhdGNoc2V0IHdoZW4gd2UgZW11
bGF0ZXMgb3RoZXIgZGVidWcgcmVnaXN0ZXJzIGZvciBndWVzdD8NCg0KPiANCj4gLVNjb3R0DQo+
IA0KDQo

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Scott Wood]

On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, June 27, 2014 11:53 PM
> > To: Bhushan Bharat-R65777
> > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> > Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> > guest
> > 
> > On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> > > -	/* Force enable debug interrupts when user space wants to debug */
> > > -	if (vcpu->guest_debug) {
> > > +	/*
> > > +	 * Force enable debug interrupts when user space wants to debug
> > > +	 * and there is no debug interrupt pending for guest to handle.
> > > +	 */
> > > +	if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
> > 
> > Are you trying to allow the guest to be simultaneously debugged by itself and by
> > host userspace?  How does this work?
> 
> Not actually, Currently we are not partitioning debug resources between
> host userspace and guest. In fact we do not emulate debug registers for
> guest. But we want host userspace to pass the interrupt to guest if it
> is not able to handle. 

I don't understand the logic here.  A debug interrupt should be injected
when the programming model in the guest says that a debug interrupt
should happen.  How can that occur currently?  If the guest didn't set
up the debug registers and QEMU still can't handle the debug interrupt,
that's a bug in QEMU (or KVM, or the hardware...).  Injecting the
interrupt into the guest just adds another bug on top of that.

> > >  #ifdef CONFIG_KVM_BOOKE_HV
> > >  		/*
> > >  		 * Since there is no shadow MSR, sync MSR_DE into the guest @@
> > > -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu
> > *vcpu)
> > >  	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
> > > }
> > >
> > > +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
> > > +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
> > > +
> > > +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
> > > +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions); }
> > 
> > Is there currently no support for a guest debugging itself (i.e.
> > guest_debug unset) on e500v2?
> 
> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet emulated). 

How is it useful to inject a debug exception into the guest, until these
things are emulated?

> > > @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
> > >  	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
> > >  		kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
> > >
> > > +	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
> > > +		vcpu->arch.dbsr = sregs->u.e.dbsr;
> > > +		if (vcpu->arch.dbsr)
> > > +			kvmppc_core_queue_debug(vcpu);
> > > +		else
> > > +			kvmppc_core_dequeue_debug(vcpu);
> > > +	}
> > > +
> > >  	return 0;
> > >  }
> > 
> > one reg?
> 
> We are using SREGS but if required we can use one_reg.

I thought we were preferring one reg over sregs for new functionality.

-Scott

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Scott Wood]

On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, June 27, 2014 11:53 PM
> > To: Bhushan Bharat-R65777
> > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> > Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> > guest
> > 
> > On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> > > -	/* Force enable debug interrupts when user space wants to debug */
> > > -	if (vcpu->guest_debug) {
> > > +	/*
> > > +	 * Force enable debug interrupts when user space wants to debug
> > > +	 * and there is no debug interrupt pending for guest to handle.
> > > +	 */
> > > +	if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
> > 
> > Are you trying to allow the guest to be simultaneously debugged by itself and by
> > host userspace?  How does this work?
> 
> Not actually, Currently we are not partitioning debug resources between
> host userspace and guest. In fact we do not emulate debug registers for
> guest. But we want host userspace to pass the interrupt to guest if it
> is not able to handle. 

I don't understand the logic here.  A debug interrupt should be injected
when the programming model in the guest says that a debug interrupt
should happen.  How can that occur currently?  If the guest didn't set
up the debug registers and QEMU still can't handle the debug interrupt,
that's a bug in QEMU (or KVM, or the hardware...).  Injecting the
interrupt into the guest just adds another bug on top of that.

> > >  #ifdef CONFIG_KVM_BOOKE_HV
> > >  		/*
> > >  		 * Since there is no shadow MSR, sync MSR_DE into the guest @@
> > > -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu
> > *vcpu)
> > >  	clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
> > > }
> > >
> > > +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
> > > +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
> > > +
> > > +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
> > > +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions); }
> > 
> > Is there currently no support for a guest debugging itself (i.e.
> > guest_debug unset) on e500v2?
> 
> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet emulated). 

How is it useful to inject a debug exception into the guest, until these
things are emulated?

> > > @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
> > >  	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
> > >  		kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
> > >
> > > +	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
> > > +		vcpu->arch.dbsr = sregs->u.e.dbsr;
> > > +		if (vcpu->arch.dbsr)
> > > +			kvmppc_core_queue_debug(vcpu);
> > > +		else
> > > +			kvmppc_core_dequeue_debug(vcpu);
> > > +	}
> > > +
> > >  	return 0;
> > >  }
> > 
> > one reg?
> 
> We are using SREGS but if required we can use one_reg.

I thought we were preferring one reg over sregs for new functionality.

-Scott

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 01, 2014 1:56 AM
> To: Bhushan Bharat-R65777
> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> guest
> 
> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Friday, June 27, 2014 11:53 PM
> > > To: Bhushan Bharat-R65777
> > > Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> > > Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
> > > injection to guest
> > >
> > > On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> > > > -	/* Force enable debug interrupts when user space wants to debug */
> > > > -	if (vcpu->guest_debug) {
> > > > +	/*
> > > > +	 * Force enable debug interrupts when user space wants to debug
> > > > +	 * and there is no debug interrupt pending for guest to handle.
> > > > +	 */
> > > > +	if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
> > >
> > > Are you trying to allow the guest to be simultaneously debugged by
> > > itself and by host userspace?  How does this work?
> >
> > Not actually, Currently we are not partitioning debug resources
> > between host userspace and guest. In fact we do not emulate debug
> > registers for guest. But we want host userspace to pass the interrupt
> > to guest if it is not able to handle.
> 
> I don't understand the logic here.  A debug interrupt should be injected when
> the programming model in the guest says that a debug interrupt should happen.
> How can that occur currently?  If the guest didn't set up the debug registers
> and QEMU still can't handle the debug interrupt, that's a bug in QEMU (or KVM,
> or the hardware...).  Injecting the interrupt into the guest just adds another
> bug on top of that.

Ok, Till we add support for guest to used debug resource, can we say that userspace will still try to inject debug interrupt (as it does not know guest capability) to guest but KVM will
 - clear guest dbsr
 - ratelimited_printk()

Suggestions please ?

Thanks
-Bharat

> 
> > > >  #ifdef CONFIG_KVM_BOOKE_HV
> > > >  		/*
> > > >  		 * Since there is no shadow MSR, sync MSR_DE into the guest
> @@
> > > > -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct
> > > > kvm_vcpu
> > > *vcpu)
> > > >  	clear_bit(BOOKE_IRQPRIO_WATCHDOG,
> > > > &vcpu->arch.pending_exceptions); }
> > > >
> > > > +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
> > > > +	kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
> > > > +
> > > > +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
> > > > +	clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions);
> > > > +}
> > >
> > > Is there currently no support for a guest debugging itself (i.e.
> > > guest_debug unset) on e500v2?
> >
> > Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet emulated).
> 
> How is it useful to inject a debug exception into the guest, until these things
> are emulated?
> 
> > > > @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
> > > >  	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
> > > >  		kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
> > > >
> > > > +	if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
> > > > +		vcpu->arch.dbsr = sregs->u.e.dbsr;
> > > > +		if (vcpu->arch.dbsr)
> > > > +			kvmppc_core_queue_debug(vcpu);
> > > > +		else
> > > > +			kvmppc_core_dequeue_debug(vcpu);
> > > > +	}
> > > > +
> > > >  	return 0;
> > > >  }
> > >
> > > one reg?
> >
> > We are using SREGS but if required we can use one_reg.
> 
> I thought we were preferring one reg over sregs for new functionality.
> 
> -Scott
> 

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgSnVseSAwMSwgMjAxNCAxOjU2IEFNDQo+IFRvOiBCaHVzaGFu
IEJoYXJhdC1SNjU3NzcNCj4gQ2M6IGFncmFmQHN1c2UuZGU7IGt2bS1wcGNAdmdlci5rZXJuZWwu
b3JnOyBrdm1Admdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8yXSBLVk0g
OiBwb3dlcnBjL2Jvb2tlOiBBbGxvdyBkZWJ1ZyBpbnRlcnJ1cHQgaW5qZWN0aW9uIHRvDQo+IGd1
ZXN0DQo+IA0KPiBPbiBTdW4sIDIwMTQtMDYtMjkgYXQgMjM6MzggLTA1MDAsIEJodXNoYW4gQmhh
cmF0LVI2NTc3NyB3cm90ZToNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N
Cj4gPiA+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gPiBTZW50OiBGcmlkYXksIEp1bmUg
MjcsIDIwMTQgMTE6NTMgUE0NCj4gPiA+IFRvOiBCaHVzaGFuIEJoYXJhdC1SNjU3NzcNCj4gPiA+
IENjOiBhZ3JhZkBzdXNlLmRlOyBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsga3ZtQHZnZXIua2Vy
bmVsLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzJdIEtWTSA6IHBvd2VycGMvYm9v
a2U6IEFsbG93IGRlYnVnIGludGVycnVwdA0KPiA+ID4gaW5qZWN0aW9uIHRvIGd1ZXN0DQo+ID4g
Pg0KPiA+ID4gT24gRnJpLCAyMDE0LTA2LTI3IGF0IDExOjU1ICswNTMwLCBCaGFyYXQgQmh1c2hh
biB3cm90ZToNCj4gPiA+ID4gLQkvKiBGb3JjZSBlbmFibGUgZGVidWcgaW50ZXJydXB0cyB3aGVu
IHVzZXIgc3BhY2Ugd2FudHMgdG8gZGVidWcgKi8NCj4gPiA+ID4gLQlpZiAodmNwdS0+Z3Vlc3Rf
ZGVidWcpIHsNCj4gPiA+ID4gKwkvKg0KPiA+ID4gPiArCSAqIEZvcmNlIGVuYWJsZSBkZWJ1ZyBp
bnRlcnJ1cHRzIHdoZW4gdXNlciBzcGFjZSB3YW50cyB0byBkZWJ1Zw0KPiA+ID4gPiArCSAqIGFu
ZCB0aGVyZSBpcyBubyBkZWJ1ZyBpbnRlcnJ1cHQgcGVuZGluZyBmb3IgZ3Vlc3QgdG8gaGFuZGxl
Lg0KPiA+ID4gPiArCSAqLw0KPiA+ID4gPiArCWlmICh2Y3B1LT5ndWVzdF9kZWJ1ZyAmJiAha3Zt
cHBjX2NvcmVfcGVuZGluZ19kZWJ1Zyh2Y3B1KSkgew0KPiA+ID4NCj4gPiA+IEFyZSB5b3UgdHJ5
aW5nIHRvIGFsbG93IHRoZSBndWVzdCB0byBiZSBzaW11bHRhbmVvdXNseSBkZWJ1Z2dlZCBieQ0K
PiA+ID4gaXRzZWxmIGFuZCBieSBob3N0IHVzZXJzcGFjZT8gIEhvdyBkb2VzIHRoaXMgd29yaz8N
Cj4gPg0KPiA+IE5vdCBhY3R1YWxseSwgQ3VycmVudGx5IHdlIGFyZSBub3QgcGFydGl0aW9uaW5n
IGRlYnVnIHJlc291cmNlcw0KPiA+IGJldHdlZW4gaG9zdCB1c2Vyc3BhY2UgYW5kIGd1ZXN0LiBJ
biBmYWN0IHdlIGRvIG5vdCBlbXVsYXRlIGRlYnVnDQo+ID4gcmVnaXN0ZXJzIGZvciBndWVzdC4g
QnV0IHdlIHdhbnQgaG9zdCB1c2Vyc3BhY2UgdG8gcGFzcyB0aGUgaW50ZXJydXB0DQo+ID4gdG8g
Z3Vlc3QgaWYgaXQgaXMgbm90IGFibGUgdG8gaGFuZGxlLg0KPiANCj4gSSBkb24ndCB1bmRlcnN0
YW5kIHRoZSBsb2dpYyBoZXJlLiAgQSBkZWJ1ZyBpbnRlcnJ1cHQgc2hvdWxkIGJlIGluamVjdGVk
IHdoZW4NCj4gdGhlIHByb2dyYW1taW5nIG1vZGVsIGluIHRoZSBndWVzdCBzYXlzIHRoYXQgYSBk
ZWJ1ZyBpbnRlcnJ1cHQgc2hvdWxkIGhhcHBlbi4NCj4gSG93IGNhbiB0aGF0IG9jY3VyIGN1cnJl
bnRseT8gIElmIHRoZSBndWVzdCBkaWRuJ3Qgc2V0IHVwIHRoZSBkZWJ1ZyByZWdpc3RlcnMNCj4g
YW5kIFFFTVUgc3RpbGwgY2FuJ3QgaGFuZGxlIHRoZSBkZWJ1ZyBpbnRlcnJ1cHQsIHRoYXQncyBh
IGJ1ZyBpbiBRRU1VIChvciBLVk0sDQo+IG9yIHRoZSBoYXJkd2FyZS4uLikuICBJbmplY3Rpbmcg
dGhlIGludGVycnVwdCBpbnRvIHRoZSBndWVzdCBqdXN0IGFkZHMgYW5vdGhlcg0KPiBidWcgb24g
dG9wIG9mIHRoYXQuDQoNCk9rLCBUaWxsIHdlIGFkZCBzdXBwb3J0IGZvciBndWVzdCB0byB1c2Vk
IGRlYnVnIHJlc291cmNlLCBjYW4gd2Ugc2F5IHRoYXQgdXNlcnNwYWNlIHdpbGwgc3RpbGwgdHJ5
IHRvIGluamVjdCBkZWJ1ZyBpbnRlcnJ1cHQgKGFzIGl0IGRvZXMgbm90IGtub3cgZ3Vlc3QgY2Fw
YWJpbGl0eSkgdG8gZ3Vlc3QgYnV0IEtWTSB3aWxsDQogLSBjbGVhciBndWVzdCBkYnNyDQogLSBy
YXRlbGltaXRlZF9wcmludGsoKQ0KDQpTdWdnZXN0aW9ucyBwbGVhc2UgPw0KDQpUaGFua3MNCi1C
aGFyYXQNCg0KPiANCj4gPiA+ID4gICNpZmRlZiBDT05GSUdfS1ZNX0JPT0tFX0hWDQo+ID4gPiA+
ICAJCS8qDQo+ID4gPiA+ICAJCSAqIFNpbmNlIHRoZXJlIGlzIG5vIHNoYWRvdyBNU1IsIHN5bmMg
TVNSX0RFIGludG8gdGhlIGd1ZXN0DQo+IEBADQo+ID4gPiA+IC0yNjQsNiArMjcyLDE2IEBAIHN0
YXRpYyB2b2lkIGt2bXBwY19jb3JlX2RlcXVldWVfd2F0Y2hkb2coc3RydWN0DQo+ID4gPiA+IGt2
bV92Y3B1DQo+ID4gPiAqdmNwdSkNCj4gPiA+ID4gIAljbGVhcl9iaXQoQk9PS0VfSVJRUFJJT19X
QVRDSERPRywNCj4gPiA+ID4gJnZjcHUtPmFyY2gucGVuZGluZ19leGNlcHRpb25zKTsgfQ0KPiA+
ID4gPg0KPiA+ID4gPiArc3RhdGljIHZvaWQga3ZtcHBjX2NvcmVfcXVldWVfZGVidWcoc3RydWN0
IGt2bV92Y3B1ICp2Y3B1KSB7DQo+ID4gPiA+ICsJa3ZtcHBjX2Jvb2tlX3F1ZXVlX2lycXByaW8o
dmNwdSwgQk9PS0VfSVJRUFJJT19ERUJVRyk7IH0NCj4gPiA+ID4gKw0KPiA+ID4gPiArc3RhdGlj
IHZvaWQga3ZtcHBjX2NvcmVfZGVxdWV1ZV9kZWJ1ZyhzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUpIHsN
Cj4gPiA+ID4gKwljbGVhcl9iaXQoQk9PS0VfSVJRUFJJT19ERUJVRywgJnZjcHUtPmFyY2gucGVu
ZGluZ19leGNlcHRpb25zKTsNCj4gPiA+ID4gK30NCj4gPiA+DQo+ID4gPiBJcyB0aGVyZSBjdXJy
ZW50bHkgbm8gc3VwcG9ydCBmb3IgYSBndWVzdCBkZWJ1Z2dpbmcgaXRzZWxmIChpLmUuDQo+ID4g
PiBndWVzdF9kZWJ1ZyB1bnNldCkgb24gZTUwMHYyPw0KPiA+DQo+ID4gWWVzLCBJdCBpcyBub3Qg
eWV0IHN1cHBvcnRlZCAoSUFDeC9EQUN4L0RCQ1IvREJTUi9EU1JSeCBhcmUgbm90IHlldCBlbXVs
YXRlZCkuDQo+IA0KPiBIb3cgaXMgaXQgdXNlZnVsIHRvIGluamVjdCBhIGRlYnVnIGV4Y2VwdGlv
biBpbnRvIHRoZSBndWVzdCwgdW50aWwgdGhlc2UgdGhpbmdzDQo+IGFyZSBlbXVsYXRlZD8NCj4g
DQo+ID4gPiA+IEBAIHN0YXRpYyBpbnQgc2V0X3NyZWdzX2Jhc2Uoc3RydWN0IGt2bV92Y3B1ICp2
Y3B1LA0KPiA+ID4gPiAgCWlmIChzcmVncy0+dS5lLnVwZGF0ZV9zcGVjaWFsICYgS1ZNX1NSRUdT
X0VfVVBEQVRFX1RTUikNCj4gPiA+ID4gIAkJa3ZtcHBjX3NldF90c3IodmNwdSwgc3JlZ3MtPnUu
ZS50c3IpOw0KPiA+ID4gPg0KPiA+ID4gPiArCWlmIChzcmVncy0+dS5lLnVwZGF0ZV9zcGVjaWFs
ICYgS1ZNX1NSRUdTX0VfVVBEQVRFX0RCU1IpIHsNCj4gPiA+ID4gKwkJdmNwdS0+YXJjaC5kYnNy
ID0gc3JlZ3MtPnUuZS5kYnNyOw0KPiA+ID4gPiArCQlpZiAodmNwdS0+YXJjaC5kYnNyKQ0KPiA+
ID4gPiArCQkJa3ZtcHBjX2NvcmVfcXVldWVfZGVidWcodmNwdSk7DQo+ID4gPiA+ICsJCWVsc2UN
Cj4gPiA+ID4gKwkJCWt2bXBwY19jb3JlX2RlcXVldWVfZGVidWcodmNwdSk7DQo+ID4gPiA+ICsJ
fQ0KPiA+ID4gPiArDQo+ID4gPiA+ICAJcmV0dXJuIDA7DQo+ID4gPiA+ICB9DQo+ID4gPg0KPiA+
ID4gb25lIHJlZz8NCj4gPg0KPiA+IFdlIGFyZSB1c2luZyBTUkVHUyBidXQgaWYgcmVxdWlyZWQg
d2UgY2FuIHVzZSBvbmVfcmVnLg0KPiANCj4gSSB0aG91Z2h0IHdlIHdlcmUgcHJlZmVycmluZyBv
bmUgcmVnIG92ZXIgc3JlZ3MgZm9yIG5ldyBmdW5jdGlvbmFsaXR5Lg0KPiANCj4gLVNjb3R0DQo+
IA0KDQo

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

> Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
> 
>> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
>> 
>>> -----Original Message-----
>>> From: Wood Scott-B07421
>>> Sent: Friday, June 27, 2014 11:53 PM
>>> To: Bhushan Bharat-R65777
>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>>> guest
>>> 
>>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
>>>> -    /* Force enable debug interrupts when user space wants to debug */
>>>> -    if (vcpu->guest_debug) {
>>>> +    /*
>>>> +     * Force enable debug interrupts when user space wants to debug
>>>> +     * and there is no debug interrupt pending for guest to handle.
>>>> +     */
>>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
>>> 
>>> Are you trying to allow the guest to be simultaneously debugged by itself and by
>>> host userspace?  How does this work?
>> 
>> Not actually, Currently we are not partitioning debug resources between
>> host userspace and guest. In fact we do not emulate debug registers for
>> guest. But we want host userspace to pass the interrupt to guest if it
>> is not able to handle.
> 
> I don't understand the logic here.  A debug interrupt should be injected
> when the programming model in the guest says that a debug interrupt
> should happen.  How can that occur currently?  If the guest didn't set
> up the debug registers and QEMU still can't handle the debug interrupt,
> that's a bug in QEMU (or KVM, or the hardware...).  Injecting the
> interrupt into the guest just adds another bug on top of that.

I don't think QEMU should be aware of these limitations.

> 
>>>> #ifdef CONFIG_KVM_BOOKE_HV
>>>>        /*
>>>>         * Since there is no shadow MSR, sync MSR_DE into the guest @@
>>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu
>>> *vcpu)
>>>>    clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
>>>> }
>>>> 
>>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
>>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
>>>> +
>>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
>>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions); }
>>> 
>>> Is there currently no support for a guest debugging itself (i.e.
>>> guest_debug unset) on e500v2?
>> 
>> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet emulated).
> 
> How is it useful to inject a debug exception into the guest, until these
> things are emulated?

We don't have to touch QEMU later then ;). But I agree that it would make a lot of sense to enable guest debugging along the way - it can't be that hard, no?

> 
>>>> @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
>>>>    if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
>>>>        kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
>>>> 
>>>> +    if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
>>>> +        vcpu->arch.dbsr = sregs->u.e.dbsr;
>>>> +        if (vcpu->arch.dbsr)
>>>> +            kvmppc_core_queue_debug(vcpu);
>>>> +        else
>>>> +            kvmppc_core_dequeue_debug(vcpu);
>>>> +    }
>>>> +
>>>>    return 0;
>>>> }
>>> 
>>> one reg?
>> 
>> We are using SREGS but if required we can use one_reg.
> 
> I thought we were preferring one reg over sregs for new functionality.

I'm personally torn on this one. The problem here is that the sregs fields and values are already reserved. For anything we don't have an API for yet, yes, one_reg only. IIUC we have the API here, but were lacking the implementation.


Alex

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

> Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
> 
>> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
>> 
>>> -----Original Message-----
>>> From: Wood Scott-B07421
>>> Sent: Friday, June 27, 2014 11:53 PM
>>> To: Bhushan Bharat-R65777
>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>>> guest
>>> 
>>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
>>>> -    /* Force enable debug interrupts when user space wants to debug */
>>>> -    if (vcpu->guest_debug) {
>>>> +    /*
>>>> +     * Force enable debug interrupts when user space wants to debug
>>>> +     * and there is no debug interrupt pending for guest to handle.
>>>> +     */
>>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
>>> 
>>> Are you trying to allow the guest to be simultaneously debugged by itself and by
>>> host userspace?  How does this work?
>> 
>> Not actually, Currently we are not partitioning debug resources between
>> host userspace and guest. In fact we do not emulate debug registers for
>> guest. But we want host userspace to pass the interrupt to guest if it
>> is not able to handle.
> 
> I don't understand the logic here.  A debug interrupt should be injected
> when the programming model in the guest says that a debug interrupt
> should happen.  How can that occur currently?  If the guest didn't set
> up the debug registers and QEMU still can't handle the debug interrupt,
> that's a bug in QEMU (or KVM, or the hardware...).  Injecting the
> interrupt into the guest just adds another bug on top of that.

I don't think QEMU should be aware of these limitations.

> 
>>>> #ifdef CONFIG_KVM_BOOKE_HV
>>>>        /*
>>>>         * Since there is no shadow MSR, sync MSR_DE into the guest @@
>>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct kvm_vcpu
>>> *vcpu)
>>>>    clear_bit(BOOKE_IRQPRIO_WATCHDOG, &vcpu->arch.pending_exceptions);
>>>> }
>>>> 
>>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
>>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
>>>> +
>>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
>>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG, &vcpu->arch.pending_exceptions); }
>>> 
>>> Is there currently no support for a guest debugging itself (i.e.
>>> guest_debug unset) on e500v2?
>> 
>> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet emulated).
> 
> How is it useful to inject a debug exception into the guest, until these
> things are emulated?

We don't have to touch QEMU later then ;). But I agree that it would make a lot of sense to enable guest debugging along the way - it can't be that hard, no?

> 
>>>> @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
>>>>    if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
>>>>        kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
>>>> 
>>>> +    if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
>>>> +        vcpu->arch.dbsr = sregs->u.e.dbsr;
>>>> +        if (vcpu->arch.dbsr)
>>>> +            kvmppc_core_queue_debug(vcpu);
>>>> +        else
>>>> +            kvmppc_core_dequeue_debug(vcpu);
>>>> +    }
>>>> +
>>>>    return 0;
>>>> }
>>> 
>>> one reg?
>> 
>> We are using SREGS but if required we can use one_reg.
> 
> I thought we were preferring one reg over sregs for new functionality.

I'm personally torn on this one. The problem here is that the sregs fields and values are already reserved. For anything we don't have an API for yet, yes, one_reg only. IIUC we have the API here, but were lacking the implementation.


Alex

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Tuesday, July 01, 2014 11:53 AM
> To: Wood Scott-B07421
> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> guest
> 
> 
> 
> > Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
> >
> >> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
> >>
> >>> -----Original Message-----
> >>> From: Wood Scott-B07421
> >>> Sent: Friday, June 27, 2014 11:53 PM
> >>> To: Bhushan Bharat-R65777
> >>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> >>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
> >>> injection to guest
> >>>
> >>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> >>>> -    /* Force enable debug interrupts when user space wants to debug */
> >>>> -    if (vcpu->guest_debug) {
> >>>> +    /*
> >>>> +     * Force enable debug interrupts when user space wants to debug
> >>>> +     * and there is no debug interrupt pending for guest to handle.
> >>>> +     */
> >>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
> >>>
> >>> Are you trying to allow the guest to be simultaneously debugged by
> >>> itself and by host userspace?  How does this work?
> >>
> >> Not actually, Currently we are not partitioning debug resources
> >> between host userspace and guest. In fact we do not emulate debug
> >> registers for guest. But we want host userspace to pass the interrupt
> >> to guest if it is not able to handle.
> >
> > I don't understand the logic here.  A debug interrupt should be
> > injected when the programming model in the guest says that a debug
> > interrupt should happen.  How can that occur currently?  If the guest
> > didn't set up the debug registers and QEMU still can't handle the
> > debug interrupt, that's a bug in QEMU (or KVM, or the hardware...).
> > Injecting the interrupt into the guest just adds another bug on top of that.
> 
> I don't think QEMU should be aware of these limitations.
> 
> >
> >>>> #ifdef CONFIG_KVM_BOOKE_HV
> >>>>        /*
> >>>>         * Since there is no shadow MSR, sync MSR_DE into the guest
> >>>> @@
> >>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct
> >>>> kvm_vcpu
> >>> *vcpu)
> >>>>    clear_bit(BOOKE_IRQPRIO_WATCHDOG,
> >>>> &vcpu->arch.pending_exceptions); }
> >>>>
> >>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
> >>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
> >>>> +
> >>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
> >>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG,
> >>>> +&vcpu->arch.pending_exceptions); }
> >>>
> >>> Is there currently no support for a guest debugging itself (i.e.
> >>> guest_debug unset) on e500v2?
> >>
> >> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet
> emulated).
> >
> > How is it useful to inject a debug exception into the guest, until
> > these things are emulated?
> 
> We don't have to touch QEMU later then ;). But I agree that it would make a lot
> of sense to enable guest debugging along the way - it can't be that hard, no?

Copy pasting my response in another email:

"
Ok, Till we add support for guest to used debug resource, can we say that userspace will still try to inject debug interrupt (as it does not know guest capability) to guest but KVM will:
 - clear guest dbsr
 - ratelimited_printk()
"

Thanks
-Bharat

> 
> >
> >>>> @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
> >>>>    if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
> >>>>        kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
> >>>>
> >>>> +    if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
> >>>> +        vcpu->arch.dbsr = sregs->u.e.dbsr;
> >>>> +        if (vcpu->arch.dbsr)
> >>>> +            kvmppc_core_queue_debug(vcpu);
> >>>> +        else
> >>>> +            kvmppc_core_dequeue_debug(vcpu);
> >>>> +    }
> >>>> +
> >>>>    return 0;
> >>>> }
> >>>
> >>> one reg?
> >>
> >> We are using SREGS but if required we can use one_reg.
> >
> > I thought we were preferring one reg over sregs for new functionality.
> 
> I'm personally torn on this one. The problem here is that the sregs fields and
> values are already reserved. For anything we don't have an API for yet, yes,
> one_reg only. IIUC we have the API here, but were lacking the implementation.
> 
> 
> Alex

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Tuesday, July 01, 2014 11:53 AM
> To: Wood Scott-B07421
> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> guest
> 
> 
> 
> > Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
> >
> >> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
> >>
> >>> -----Original Message-----
> >>> From: Wood Scott-B07421
> >>> Sent: Friday, June 27, 2014 11:53 PM
> >>> To: Bhushan Bharat-R65777
> >>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> >>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
> >>> injection to guest
> >>>
> >>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> >>>> -    /* Force enable debug interrupts when user space wants to debug */
> >>>> -    if (vcpu->guest_debug) {
> >>>> +    /*
> >>>> +     * Force enable debug interrupts when user space wants to debug
> >>>> +     * and there is no debug interrupt pending for guest to handle.
> >>>> +     */
> >>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
> >>>
> >>> Are you trying to allow the guest to be simultaneously debugged by
> >>> itself and by host userspace?  How does this work?
> >>
> >> Not actually, Currently we are not partitioning debug resources
> >> between host userspace and guest. In fact we do not emulate debug
> >> registers for guest. But we want host userspace to pass the interrupt
> >> to guest if it is not able to handle.
> >
> > I don't understand the logic here.  A debug interrupt should be
> > injected when the programming model in the guest says that a debug
> > interrupt should happen.  How can that occur currently?  If the guest
> > didn't set up the debug registers and QEMU still can't handle the
> > debug interrupt, that's a bug in QEMU (or KVM, or the hardware...).
> > Injecting the interrupt into the guest just adds another bug on top of that.
> 
> I don't think QEMU should be aware of these limitations.
> 
> >
> >>>> #ifdef CONFIG_KVM_BOOKE_HV
> >>>>        /*
> >>>>         * Since there is no shadow MSR, sync MSR_DE into the guest
> >>>> @@
> >>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct
> >>>> kvm_vcpu
> >>> *vcpu)
> >>>>    clear_bit(BOOKE_IRQPRIO_WATCHDOG,
> >>>> &vcpu->arch.pending_exceptions); }
> >>>>
> >>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
> >>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
> >>>> +
> >>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
> >>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG,
> >>>> +&vcpu->arch.pending_exceptions); }
> >>>
> >>> Is there currently no support for a guest debugging itself (i.e.
> >>> guest_debug unset) on e500v2?
> >>
> >> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet
> emulated).
> >
> > How is it useful to inject a debug exception into the guest, until
> > these things are emulated?
> 
> We don't have to touch QEMU later then ;). But I agree that it would make a lot
> of sense to enable guest debugging along the way - it can't be that hard, no?

Copy pasting my response in another email:

"
Ok, Till we add support for guest to used debug resource, can we say that userspace will still try to inject debug interrupt (as it does not know guest capability) to guest but KVM will:
 - clear guest dbsr
 - ratelimited_printk()
"

Thanks
-Bharat

> 
> >
> >>>> @@ static int set_sregs_base(struct kvm_vcpu *vcpu,
> >>>>    if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_TSR)
> >>>>        kvmppc_set_tsr(vcpu, sregs->u.e.tsr);
> >>>>
> >>>> +    if (sregs->u.e.update_special & KVM_SREGS_E_UPDATE_DBSR) {
> >>>> +        vcpu->arch.dbsr = sregs->u.e.dbsr;
> >>>> +        if (vcpu->arch.dbsr)
> >>>> +            kvmppc_core_queue_debug(vcpu);
> >>>> +        else
> >>>> +            kvmppc_core_dequeue_debug(vcpu);
> >>>> +    }
> >>>> +
> >>>>    return 0;
> >>>> }
> >>>
> >>> one reg?
> >>
> >> We are using SREGS but if required we can use one_reg.
> >
> > I thought we were preferring one reg over sregs for new functionality.
> 
> I'm personally torn on this one. The problem here is that the sregs fields and
> values are already reserved. For anything we don't have an API for yet, yes,
> one_reg only. IIUC we have the API here, but were lacking the implementation.
> 
> 
> Alex

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

On 01.07.14 12:06, Bharat.Bhushan@freescale.com wrote:
>
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Tuesday, July 01, 2014 11:53 AM
>> To: Wood Scott-B07421
>> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>> guest
>>
>>
>>
>>> Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
>>>
>>>> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Wood Scott-B07421
>>>>> Sent: Friday, June 27, 2014 11:53 PM
>>>>> To: Bhushan Bharat-R65777
>>>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
>>>>> injection to guest
>>>>>
>>>>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
>>>>>> -    /* Force enable debug interrupts when user space wants to debug */
>>>>>> -    if (vcpu->guest_debug) {
>>>>>> +    /*
>>>>>> +     * Force enable debug interrupts when user space wants to debug
>>>>>> +     * and there is no debug interrupt pending for guest to handle.
>>>>>> +     */
>>>>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
>>>>> Are you trying to allow the guest to be simultaneously debugged by
>>>>> itself and by host userspace?  How does this work?
>>>> Not actually, Currently we are not partitioning debug resources
>>>> between host userspace and guest. In fact we do not emulate debug
>>>> registers for guest. But we want host userspace to pass the interrupt
>>>> to guest if it is not able to handle.
>>> I don't understand the logic here.  A debug interrupt should be
>>> injected when the programming model in the guest says that a debug
>>> interrupt should happen.  How can that occur currently?  If the guest
>>> didn't set up the debug registers and QEMU still can't handle the
>>> debug interrupt, that's a bug in QEMU (or KVM, or the hardware...).
>>> Injecting the interrupt into the guest just adds another bug on top of that.
>> I don't think QEMU should be aware of these limitations.
>>
>>>>>> #ifdef CONFIG_KVM_BOOKE_HV
>>>>>>         /*
>>>>>>          * Since there is no shadow MSR, sync MSR_DE into the guest
>>>>>> @@
>>>>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct
>>>>>> kvm_vcpu
>>>>> *vcpu)
>>>>>>     clear_bit(BOOKE_IRQPRIO_WATCHDOG,
>>>>>> &vcpu->arch.pending_exceptions); }
>>>>>>
>>>>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
>>>>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
>>>>>> +
>>>>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
>>>>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG,
>>>>>> +&vcpu->arch.pending_exceptions); }
>>>>> Is there currently no support for a guest debugging itself (i.e.
>>>>> guest_debug unset) on e500v2?
>>>> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet
>> emulated).
>>> How is it useful to inject a debug exception into the guest, until
>>> these things are emulated?
>> We don't have to touch QEMU later then ;). But I agree that it would make a lot
>> of sense to enable guest debugging along the way - it can't be that hard, no?
> Copy pasting my response in another email:
>
> "
> Ok, Till we add support for guest to used debug resource, can we say that userspace will still try to inject debug interrupt (as it does not know guest capability) to guest but KVM will:
>   - clear guest dbsr

Can we fake the value of DBSR that the guest sees?


Alex

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

On 01.07.14 12:06, Bharat.Bhushan@freescale.com wrote:
>
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Tuesday, July 01, 2014 11:53 AM
>> To: Wood Scott-B07421
>> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>> guest
>>
>>
>>
>>> Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
>>>
>>>> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Wood Scott-B07421
>>>>> Sent: Friday, June 27, 2014 11:53 PM
>>>>> To: Bhushan Bharat-R65777
>>>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
>>>>> injection to guest
>>>>>
>>>>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
>>>>>> -    /* Force enable debug interrupts when user space wants to debug */
>>>>>> -    if (vcpu->guest_debug) {
>>>>>> +    /*
>>>>>> +     * Force enable debug interrupts when user space wants to debug
>>>>>> +     * and there is no debug interrupt pending for guest to handle.
>>>>>> +     */
>>>>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
>>>>> Are you trying to allow the guest to be simultaneously debugged by
>>>>> itself and by host userspace?  How does this work?
>>>> Not actually, Currently we are not partitioning debug resources
>>>> between host userspace and guest. In fact we do not emulate debug
>>>> registers for guest. But we want host userspace to pass the interrupt
>>>> to guest if it is not able to handle.
>>> I don't understand the logic here.  A debug interrupt should be
>>> injected when the programming model in the guest says that a debug
>>> interrupt should happen.  How can that occur currently?  If the guest
>>> didn't set up the debug registers and QEMU still can't handle the
>>> debug interrupt, that's a bug in QEMU (or KVM, or the hardware...).
>>> Injecting the interrupt into the guest just adds another bug on top of that.
>> I don't think QEMU should be aware of these limitations.
>>
>>>>>> #ifdef CONFIG_KVM_BOOKE_HV
>>>>>>         /*
>>>>>>          * Since there is no shadow MSR, sync MSR_DE into the guest
>>>>>> @@
>>>>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct
>>>>>> kvm_vcpu
>>>>> *vcpu)
>>>>>>     clear_bit(BOOKE_IRQPRIO_WATCHDOG,
>>>>>> &vcpu->arch.pending_exceptions); }
>>>>>>
>>>>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
>>>>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
>>>>>> +
>>>>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
>>>>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG,
>>>>>> +&vcpu->arch.pending_exceptions); }
>>>>> Is there currently no support for a guest debugging itself (i.e.
>>>>> guest_debug unset) on e500v2?
>>>> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet
>> emulated).
>>> How is it useful to inject a debug exception into the guest, until
>>> these things are emulated?
>> We don't have to touch QEMU later then ;). But I agree that it would make a lot
>> of sense to enable guest debugging along the way - it can't be that hard, no?
> Copy pasting my response in another email:
>
> "
> Ok, Till we add support for guest to used debug resource, can we say that userspace will still try to inject debug interrupt (as it does not know guest capability) to guest but KVM will:
>   - clear guest dbsr

Can we fake the value of DBSR that the guest sees?


Alex

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Tuesday, July 01, 2014 3:42 PM
> To: Bhushan Bharat-R65777; Wood Scott-B07421
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> guest
> 
> 
> On 01.07.14 12:06, Bharat.Bhushan@freescale.com wrote:
> >
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf@suse.de]
> >> Sent: Tuesday, July 01, 2014 11:53 AM
> >> To: Wood Scott-B07421
> >> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org;
> >> kvm@vger.kernel.org
> >> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
> >> injection to guest
> >>
> >>
> >>
> >>> Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
> >>>
> >>>> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Wood Scott-B07421
> >>>>> Sent: Friday, June 27, 2014 11:53 PM
> >>>>> To: Bhushan Bharat-R65777
> >>>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> >>>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug
> >>>>> interrupt injection to guest
> >>>>>
> >>>>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> >>>>>> -    /* Force enable debug interrupts when user space wants to debug */
> >>>>>> -    if (vcpu->guest_debug) {
> >>>>>> +    /*
> >>>>>> +     * Force enable debug interrupts when user space wants to debug
> >>>>>> +     * and there is no debug interrupt pending for guest to handle.
> >>>>>> +     */
> >>>>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
> >>>>> Are you trying to allow the guest to be simultaneously debugged by
> >>>>> itself and by host userspace?  How does this work?
> >>>> Not actually, Currently we are not partitioning debug resources
> >>>> between host userspace and guest. In fact we do not emulate debug
> >>>> registers for guest. But we want host userspace to pass the
> >>>> interrupt to guest if it is not able to handle.
> >>> I don't understand the logic here.  A debug interrupt should be
> >>> injected when the programming model in the guest says that a debug
> >>> interrupt should happen.  How can that occur currently?  If the
> >>> guest didn't set up the debug registers and QEMU still can't handle
> >>> the debug interrupt, that's a bug in QEMU (or KVM, or the hardware...).
> >>> Injecting the interrupt into the guest just adds another bug on top of that.
> >> I don't think QEMU should be aware of these limitations.
> >>
> >>>>>> #ifdef CONFIG_KVM_BOOKE_HV
> >>>>>>         /*
> >>>>>>          * Since there is no shadow MSR, sync MSR_DE into the
> >>>>>> guest @@
> >>>>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct
> >>>>>> kvm_vcpu
> >>>>> *vcpu)
> >>>>>>     clear_bit(BOOKE_IRQPRIO_WATCHDOG,
> >>>>>> &vcpu->arch.pending_exceptions); }
> >>>>>>
> >>>>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
> >>>>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
> >>>>>> +
> >>>>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
> >>>>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG,
> >>>>>> +&vcpu->arch.pending_exceptions); }
> >>>>> Is there currently no support for a guest debugging itself (i.e.
> >>>>> guest_debug unset) on e500v2?
> >>>> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet
> >> emulated).
> >>> How is it useful to inject a debug exception into the guest, until
> >>> these things are emulated?
> >> We don't have to touch QEMU later then ;). But I agree that it would
> >> make a lot of sense to enable guest debugging along the way - it can't be
> that hard, no?
> > Copy pasting my response in another email:
> >
> > "
> > Ok, Till we add support for guest to used debug resource, can we say that
> userspace will still try to inject debug interrupt (as it does not know guest
> capability) to guest but KVM will:
> >   - clear guest dbsr
> 
> Can we fake the value of DBSR that the guest sees?

Yes; we can hack the dbsr emulation with a comment :)
But why we want that?

Thanks
-Bharat

> 
> 
> Alex

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Tuesday, July 01, 2014 3:42 PM
> To: Bhushan Bharat-R65777; Wood Scott-B07421
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> guest
> 
> 
> On 01.07.14 12:06, Bharat.Bhushan@freescale.com wrote:
> >
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf@suse.de]
> >> Sent: Tuesday, July 01, 2014 11:53 AM
> >> To: Wood Scott-B07421
> >> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org;
> >> kvm@vger.kernel.org
> >> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
> >> injection to guest
> >>
> >>
> >>
> >>> Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
> >>>
> >>>> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Wood Scott-B07421
> >>>>> Sent: Friday, June 27, 2014 11:53 PM
> >>>>> To: Bhushan Bharat-R65777
> >>>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> >>>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug
> >>>>> interrupt injection to guest
> >>>>>
> >>>>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> >>>>>> -    /* Force enable debug interrupts when user space wants to debug */
> >>>>>> -    if (vcpu->guest_debug) {
> >>>>>> +    /*
> >>>>>> +     * Force enable debug interrupts when user space wants to debug
> >>>>>> +     * and there is no debug interrupt pending for guest to handle.
> >>>>>> +     */
> >>>>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
> >>>>> Are you trying to allow the guest to be simultaneously debugged by
> >>>>> itself and by host userspace?  How does this work?
> >>>> Not actually, Currently we are not partitioning debug resources
> >>>> between host userspace and guest. In fact we do not emulate debug
> >>>> registers for guest. But we want host userspace to pass the
> >>>> interrupt to guest if it is not able to handle.
> >>> I don't understand the logic here.  A debug interrupt should be
> >>> injected when the programming model in the guest says that a debug
> >>> interrupt should happen.  How can that occur currently?  If the
> >>> guest didn't set up the debug registers and QEMU still can't handle
> >>> the debug interrupt, that's a bug in QEMU (or KVM, or the hardware...).
> >>> Injecting the interrupt into the guest just adds another bug on top of that.
> >> I don't think QEMU should be aware of these limitations.
> >>
> >>>>>> #ifdef CONFIG_KVM_BOOKE_HV
> >>>>>>         /*
> >>>>>>          * Since there is no shadow MSR, sync MSR_DE into the
> >>>>>> guest @@
> >>>>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct
> >>>>>> kvm_vcpu
> >>>>> *vcpu)
> >>>>>>     clear_bit(BOOKE_IRQPRIO_WATCHDOG,
> >>>>>> &vcpu->arch.pending_exceptions); }
> >>>>>>
> >>>>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
> >>>>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
> >>>>>> +
> >>>>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
> >>>>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG,
> >>>>>> +&vcpu->arch.pending_exceptions); }
> >>>>> Is there currently no support for a guest debugging itself (i.e.
> >>>>> guest_debug unset) on e500v2?
> >>>> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet
> >> emulated).
> >>> How is it useful to inject a debug exception into the guest, until
> >>> these things are emulated?
> >> We don't have to touch QEMU later then ;). But I agree that it would
> >> make a lot of sense to enable guest debugging along the way - it can't be
> that hard, no?
> > Copy pasting my response in another email:
> >
> > "
> > Ok, Till we add support for guest to used debug resource, can we say that
> userspace will still try to inject debug interrupt (as it does not know guest
> capability) to guest but KVM will:
> >   - clear guest dbsr
> 
> Can we fake the value of DBSR that the guest sees?

Yes; we can hack the dbsr emulation with a comment :)
But why we want that?

Thanks
-Bharat

> 
> 
> Alex

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

On 01.07.14 12:30, Bharat.Bhushan@freescale.com wrote:
>
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Tuesday, July 01, 2014 3:42 PM
>> To: Bhushan Bharat-R65777; Wood Scott-B07421
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>> guest
>>
>>
>> On 01.07.14 12:06, Bharat.Bhushan@freescale.com wrote:
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf@suse.de]
>>>> Sent: Tuesday, July 01, 2014 11:53 AM
>>>> To: Wood Scott-B07421
>>>> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org;
>>>> kvm@vger.kernel.org
>>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
>>>> injection to guest
>>>>
>>>>
>>>>
>>>>> Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
>>>>>
>>>>>> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Wood Scott-B07421
>>>>>>> Sent: Friday, June 27, 2014 11:53 PM
>>>>>>> To: Bhushan Bharat-R65777
>>>>>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>>>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug
>>>>>>> interrupt injection to guest
>>>>>>>
>>>>>>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
>>>>>>>> -    /* Force enable debug interrupts when user space wants to debug */
>>>>>>>> -    if (vcpu->guest_debug) {
>>>>>>>> +    /*
>>>>>>>> +     * Force enable debug interrupts when user space wants to debug
>>>>>>>> +     * and there is no debug interrupt pending for guest to handle.
>>>>>>>> +     */
>>>>>>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
>>>>>>> Are you trying to allow the guest to be simultaneously debugged by
>>>>>>> itself and by host userspace?  How does this work?
>>>>>> Not actually, Currently we are not partitioning debug resources
>>>>>> between host userspace and guest. In fact we do not emulate debug
>>>>>> registers for guest. But we want host userspace to pass the
>>>>>> interrupt to guest if it is not able to handle.
>>>>> I don't understand the logic here.  A debug interrupt should be
>>>>> injected when the programming model in the guest says that a debug
>>>>> interrupt should happen.  How can that occur currently?  If the
>>>>> guest didn't set up the debug registers and QEMU still can't handle
>>>>> the debug interrupt, that's a bug in QEMU (or KVM, or the hardware...).
>>>>> Injecting the interrupt into the guest just adds another bug on top of that.
>>>> I don't think QEMU should be aware of these limitations.
>>>>
>>>>>>>> #ifdef CONFIG_KVM_BOOKE_HV
>>>>>>>>          /*
>>>>>>>>           * Since there is no shadow MSR, sync MSR_DE into the
>>>>>>>> guest @@
>>>>>>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct
>>>>>>>> kvm_vcpu
>>>>>>> *vcpu)
>>>>>>>>      clear_bit(BOOKE_IRQPRIO_WATCHDOG,
>>>>>>>> &vcpu->arch.pending_exceptions); }
>>>>>>>>
>>>>>>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
>>>>>>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
>>>>>>>> +
>>>>>>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
>>>>>>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG,
>>>>>>>> +&vcpu->arch.pending_exceptions); }
>>>>>>> Is there currently no support for a guest debugging itself (i.e.
>>>>>>> guest_debug unset) on e500v2?
>>>>>> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet
>>>> emulated).
>>>>> How is it useful to inject a debug exception into the guest, until
>>>>> these things are emulated?
>>>> We don't have to touch QEMU later then ;). But I agree that it would
>>>> make a lot of sense to enable guest debugging along the way - it can't be
>> that hard, no?
>>> Copy pasting my response in another email:
>>>
>>> "
>>> Ok, Till we add support for guest to used debug resource, can we say that
>> userspace will still try to inject debug interrupt (as it does not know guest
>> capability) to guest but KVM will:
>>>    - clear guest dbsr
>> Can we fake the value of DBSR that the guest sees?
> Yes; we can hack the dbsr emulation with a comment :)
> But why we want that?

I guess I don't fully grasp what you're proposing :).


Alex

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

On 01.07.14 12:30, Bharat.Bhushan@freescale.com wrote:
>
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Tuesday, July 01, 2014 3:42 PM
>> To: Bhushan Bharat-R65777; Wood Scott-B07421
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>> guest
>>
>>
>> On 01.07.14 12:06, Bharat.Bhushan@freescale.com wrote:
>>>> -----Original Message-----
>>>> From: Alexander Graf [mailto:agraf@suse.de]
>>>> Sent: Tuesday, July 01, 2014 11:53 AM
>>>> To: Wood Scott-B07421
>>>> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org;
>>>> kvm@vger.kernel.org
>>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
>>>> injection to guest
>>>>
>>>>
>>>>
>>>>> Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
>>>>>
>>>>>> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Wood Scott-B07421
>>>>>>> Sent: Friday, June 27, 2014 11:53 PM
>>>>>>> To: Bhushan Bharat-R65777
>>>>>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>>>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug
>>>>>>> interrupt injection to guest
>>>>>>>
>>>>>>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
>>>>>>>> -    /* Force enable debug interrupts when user space wants to debug */
>>>>>>>> -    if (vcpu->guest_debug) {
>>>>>>>> +    /*
>>>>>>>> +     * Force enable debug interrupts when user space wants to debug
>>>>>>>> +     * and there is no debug interrupt pending for guest to handle.
>>>>>>>> +     */
>>>>>>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
>>>>>>> Are you trying to allow the guest to be simultaneously debugged by
>>>>>>> itself and by host userspace?  How does this work?
>>>>>> Not actually, Currently we are not partitioning debug resources
>>>>>> between host userspace and guest. In fact we do not emulate debug
>>>>>> registers for guest. But we want host userspace to pass the
>>>>>> interrupt to guest if it is not able to handle.
>>>>> I don't understand the logic here.  A debug interrupt should be
>>>>> injected when the programming model in the guest says that a debug
>>>>> interrupt should happen.  How can that occur currently?  If the
>>>>> guest didn't set up the debug registers and QEMU still can't handle
>>>>> the debug interrupt, that's a bug in QEMU (or KVM, or the hardware...).
>>>>> Injecting the interrupt into the guest just adds another bug on top of that.
>>>> I don't think QEMU should be aware of these limitations.
>>>>
>>>>>>>> #ifdef CONFIG_KVM_BOOKE_HV
>>>>>>>>          /*
>>>>>>>>           * Since there is no shadow MSR, sync MSR_DE into the
>>>>>>>> guest @@
>>>>>>>> -264,6 +272,16 @@ static void kvmppc_core_dequeue_watchdog(struct
>>>>>>>> kvm_vcpu
>>>>>>> *vcpu)
>>>>>>>>      clear_bit(BOOKE_IRQPRIO_WATCHDOG,
>>>>>>>> &vcpu->arch.pending_exceptions); }
>>>>>>>>
>>>>>>>> +static void kvmppc_core_queue_debug(struct kvm_vcpu *vcpu) {
>>>>>>>> +    kvmppc_booke_queue_irqprio(vcpu, BOOKE_IRQPRIO_DEBUG); }
>>>>>>>> +
>>>>>>>> +static void kvmppc_core_dequeue_debug(struct kvm_vcpu *vcpu) {
>>>>>>>> +    clear_bit(BOOKE_IRQPRIO_DEBUG,
>>>>>>>> +&vcpu->arch.pending_exceptions); }
>>>>>>> Is there currently no support for a guest debugging itself (i.e.
>>>>>>> guest_debug unset) on e500v2?
>>>>>> Yes, It is not yet supported (IACx/DACx/DBCR/DBSR/DSRRx are not yet
>>>> emulated).
>>>>> How is it useful to inject a debug exception into the guest, until
>>>>> these things are emulated?
>>>> We don't have to touch QEMU later then ;). But I agree that it would
>>>> make a lot of sense to enable guest debugging along the way - it can't be
>> that hard, no?
>>> Copy pasting my response in another email:
>>>
>>> "
>>> Ok, Till we add support for guest to used debug resource, can we say that
>> userspace will still try to inject debug interrupt (as it does not know guest
>> capability) to guest but KVM will:
>>>    - clear guest dbsr
>> Can we fake the value of DBSR that the guest sees?
> Yes; we can hack the dbsr emulation with a comment :)
> But why we want that?

I guess I don't fully grasp what you're proposing :).


Alex

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Scott Wood]

On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
> 
> > Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
> > 
> >> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
> >> 
> >>> -----Original Message-----
> >>> From: Wood Scott-B07421
> >>> Sent: Friday, June 27, 2014 11:53 PM
> >>> To: Bhushan Bharat-R65777
> >>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> >>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> >>> guest
> >>> 
> >>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> >>>> -    /* Force enable debug interrupts when user space wants to debug */
> >>>> -    if (vcpu->guest_debug) {
> >>>> +    /*
> >>>> +     * Force enable debug interrupts when user space wants to debug
> >>>> +     * and there is no debug interrupt pending for guest to handle.
> >>>> +     */
> >>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
> >>> 
> >>> Are you trying to allow the guest to be simultaneously debugged by itself and by
> >>> host userspace?  How does this work?
> >> 
> >> Not actually, Currently we are not partitioning debug resources between
> >> host userspace and guest. In fact we do not emulate debug registers for
> >> guest. But we want host userspace to pass the interrupt to guest if it
> >> is not able to handle.
> > 
> > I don't understand the logic here.  A debug interrupt should be injected
> > when the programming model in the guest says that a debug interrupt
> > should happen.  How can that occur currently?  If the guest didn't set
> > up the debug registers and QEMU still can't handle the debug interrupt,
> > that's a bug in QEMU (or KVM, or the hardware...).  Injecting the
> > interrupt into the guest just adds another bug on top of that.
> 
> I don't think QEMU should be aware of these limitations.

OK, but we should at least have some idea of how the whole thing is
supposed to work, in order to determine if this is the correct behavior
for QEMU.  I thought the model was that debug resources are either owned
by QEMU or by the guest, and in the latter case, QEMU would never see
the debug exception to begin with.

> >>> one reg?
> >> 
> >> We are using SREGS but if required we can use one_reg.
> > 
> > I thought we were preferring one reg over sregs for new functionality.
> 
> I'm personally torn on this one. The problem here is that the sregs
> fields and values are already reserved. For anything we don't have an
> API for yet, yes, one_reg only. IIUC we have the API here, but were
> lacking the implementation.

>From a QEMU perspective, are we going to want to update this at the same
time as everything else, or would jumping through sregs hoops be a
nuisance?  Is the long term goal to have one reg support for everything?

-Scott

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Scott Wood]

On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
> 
> > Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
> > 
> >> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
> >> 
> >>> -----Original Message-----
> >>> From: Wood Scott-B07421
> >>> Sent: Friday, June 27, 2014 11:53 PM
> >>> To: Bhushan Bharat-R65777
> >>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> >>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> >>> guest
> >>> 
> >>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
> >>>> -    /* Force enable debug interrupts when user space wants to debug */
> >>>> -    if (vcpu->guest_debug) {
> >>>> +    /*
> >>>> +     * Force enable debug interrupts when user space wants to debug
> >>>> +     * and there is no debug interrupt pending for guest to handle.
> >>>> +     */
> >>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
> >>> 
> >>> Are you trying to allow the guest to be simultaneously debugged by itself and by
> >>> host userspace?  How does this work?
> >> 
> >> Not actually, Currently we are not partitioning debug resources between
> >> host userspace and guest. In fact we do not emulate debug registers for
> >> guest. But we want host userspace to pass the interrupt to guest if it
> >> is not able to handle.
> > 
> > I don't understand the logic here.  A debug interrupt should be injected
> > when the programming model in the guest says that a debug interrupt
> > should happen.  How can that occur currently?  If the guest didn't set
> > up the debug registers and QEMU still can't handle the debug interrupt,
> > that's a bug in QEMU (or KVM, or the hardware...).  Injecting the
> > interrupt into the guest just adds another bug on top of that.
> 
> I don't think QEMU should be aware of these limitations.

OK, but we should at least have some idea of how the whole thing is
supposed to work, in order to determine if this is the correct behavior
for QEMU.  I thought the model was that debug resources are either owned
by QEMU or by the guest, and in the latter case, QEMU would never see
the debug exception to begin with.

> >>> one reg?
> >> 
> >> We are using SREGS but if required we can use one_reg.
> > 
> > I thought we were preferring one reg over sregs for new functionality.
> 
> I'm personally torn on this one. The problem here is that the sregs
> fields and values are already reserved. For anything we don't have an
> API for yet, yes, one_reg only. IIUC we have the API here, but were
> lacking the implementation.

From a QEMU perspective, are we going to want to update this at the same
time as everything else, or would jumping through sregs hoops be a
nuisance?  Is the long term goal to have one reg support for everything?

-Scott

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

On 01.07.14 16:58, Scott Wood wrote:
> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
>>> Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
>>>
>>>> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Wood Scott-B07421
>>>>> Sent: Friday, June 27, 2014 11:53 PM
>>>>> To: Bhushan Bharat-R65777
>>>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>>>>> guest
>>>>>
>>>>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
>>>>>> -    /* Force enable debug interrupts when user space wants to debug */
>>>>>> -    if (vcpu->guest_debug) {
>>>>>> +    /*
>>>>>> +     * Force enable debug interrupts when user space wants to debug
>>>>>> +     * and there is no debug interrupt pending for guest to handle.
>>>>>> +     */
>>>>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
>>>>> Are you trying to allow the guest to be simultaneously debugged by itself and by
>>>>> host userspace?  How does this work?
>>>> Not actually, Currently we are not partitioning debug resources between
>>>> host userspace and guest. In fact we do not emulate debug registers for
>>>> guest. But we want host userspace to pass the interrupt to guest if it
>>>> is not able to handle.
>>> I don't understand the logic here.  A debug interrupt should be injected
>>> when the programming model in the guest says that a debug interrupt
>>> should happen.  How can that occur currently?  If the guest didn't set
>>> up the debug registers and QEMU still can't handle the debug interrupt,
>>> that's a bug in QEMU (or KVM, or the hardware...).  Injecting the
>>> interrupt into the guest just adds another bug on top of that.
>> I don't think QEMU should be aware of these limitations.
> OK, but we should at least have some idea of how the whole thing is
> supposed to work, in order to determine if this is the correct behavior
> for QEMU.  I thought the model was that debug resources are either owned
> by QEMU or by the guest, and in the latter case, QEMU would never see
> the debug exception to begin with.

That's bad for a number of reasons. For starters it's different from how 
x86 handles debug registers - and I hate to be different just for the 
sake of being different. So if we do want to declare that debug 
registers are owned by either QEMU or the guest, we should change the 
semantics for all architectures.

The second problem I see is that we're disabling use cases for the sake 
of correctness. When I use gdbstub, I usually don't want anything in the 
way of debugging something - like if I want to debug the guest debugging 
itself for example.

So overall, I think the x86 approach is a nice middle ground between 
usability, performance and functionality.

>
>>>>> one reg?
>>>> We are using SREGS but if required we can use one_reg.
>>> I thought we were preferring one reg over sregs for new functionality.
>> I'm personally torn on this one. The problem here is that the sregs
>> fields and values are already reserved. For anything we don't have an
>> API for yet, yes, one_reg only. IIUC we have the API here, but were
>> lacking the implementation.
>  From a QEMU perspective, are we going to want to update this at the same
> time as everything else, or would jumping through sregs hoops be a
> nuisance?  Is the long term goal to have one reg support for everything?

Because we need to maintain backwards compatibility, I don't think we'll 
actually have any benefit from one reg support for everything.

I think we're in a path that is slow enough already to not worry about 
performance. I think we're good to just call the sregs setter on demand 
when we want to change single registers.


Alex

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

On 01.07.14 16:58, Scott Wood wrote:
> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
>>> Am 30.06.2014 um 22:25 schrieb Scott Wood <scottwood@freescale.com>:
>>>
>>>> On Sun, 2014-06-29 at 23:38 -0500, Bhushan Bharat-R65777 wrote:
>>>>
>>>>> -----Original Message-----
>>>>> From: Wood Scott-B07421
>>>>> Sent: Friday, June 27, 2014 11:53 PM
>>>>> To: Bhushan Bharat-R65777
>>>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>>>>> guest
>>>>>
>>>>>> On Fri, 2014-06-27 at 11:55 +0530, Bharat Bhushan wrote:
>>>>>> -    /* Force enable debug interrupts when user space wants to debug */
>>>>>> -    if (vcpu->guest_debug) {
>>>>>> +    /*
>>>>>> +     * Force enable debug interrupts when user space wants to debug
>>>>>> +     * and there is no debug interrupt pending for guest to handle.
>>>>>> +     */
>>>>>> +    if (vcpu->guest_debug && !kvmppc_core_pending_debug(vcpu)) {
>>>>> Are you trying to allow the guest to be simultaneously debugged by itself and by
>>>>> host userspace?  How does this work?
>>>> Not actually, Currently we are not partitioning debug resources between
>>>> host userspace and guest. In fact we do not emulate debug registers for
>>>> guest. But we want host userspace to pass the interrupt to guest if it
>>>> is not able to handle.
>>> I don't understand the logic here.  A debug interrupt should be injected
>>> when the programming model in the guest says that a debug interrupt
>>> should happen.  How can that occur currently?  If the guest didn't set
>>> up the debug registers and QEMU still can't handle the debug interrupt,
>>> that's a bug in QEMU (or KVM, or the hardware...).  Injecting the
>>> interrupt into the guest just adds another bug on top of that.
>> I don't think QEMU should be aware of these limitations.
> OK, but we should at least have some idea of how the whole thing is
> supposed to work, in order to determine if this is the correct behavior
> for QEMU.  I thought the model was that debug resources are either owned
> by QEMU or by the guest, and in the latter case, QEMU would never see
> the debug exception to begin with.

That's bad for a number of reasons. For starters it's different from how 
x86 handles debug registers - and I hate to be different just for the 
sake of being different. So if we do want to declare that debug 
registers are owned by either QEMU or the guest, we should change the 
semantics for all architectures.

The second problem I see is that we're disabling use cases for the sake 
of correctness. When I use gdbstub, I usually don't want anything in the 
way of debugging something - like if I want to debug the guest debugging 
itself for example.

So overall, I think the x86 approach is a nice middle ground between 
usability, performance and functionality.

>
>>>>> one reg?
>>>> We are using SREGS but if required we can use one_reg.
>>> I thought we were preferring one reg over sregs for new functionality.
>> I'm personally torn on this one. The problem here is that the sregs
>> fields and values are already reserved. For anything we don't have an
>> API for yet, yes, one_reg only. IIUC we have the API here, but were
>> lacking the implementation.
>  From a QEMU perspective, are we going to want to update this at the same
> time as everything else, or would jumping through sregs hoops be a
> nuisance?  Is the long term goal to have one reg support for everything?

Because we need to maintain backwards compatibility, I don't think we'll 
actually have any benefit from one reg support for everything.

I think we're in a path that is slow enough already to not worry about 
performance. I think we're good to just call the sregs setter on demand 
when we want to change single registers.


Alex

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Scott Wood]

On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
> On 01.07.14 16:58, Scott Wood wrote:
> > On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
> >> I don't think QEMU should be aware of these limitations.
> > OK, but we should at least have some idea of how the whole thing is
> > supposed to work, in order to determine if this is the correct behavior
> > for QEMU.  I thought the model was that debug resources are either owned
> > by QEMU or by the guest, and in the latter case, QEMU would never see
> > the debug exception to begin with.
> 
> That's bad for a number of reasons. For starters it's different from how 
> x86 handles debug registers - and I hate to be different just for the 
> sake of being different.

How does it work on x86?

> So if we do want to declare that debug registers are owned by either
> QEMU or the guest, we should change the semantics for all
> architectures.

If we want to say that ownership of the registers is shared, we need a
plan for how that would actually work.

> The second problem I see is that we're disabling use cases for the sake 
> of correctness. When I use gdbstub, I usually don't want anything in the 
> way of debugging something - like if I want to debug the guest debugging 
> itself for example.

I don't have a problem with making it possible for userspace to forcibly
claim ownership of the debug registers -- but I don't want to advertise
that won't mess up the guest debugging that you're trying to debug,
without some reason to believe that.

> So overall, I think the x86 approach is a nice middle ground between 
> usability, performance and functionality.

You mean don't document anything other than the mechanism to get/set the
registers and hope everything works out? :-)

> >>>>> one reg?
> >>>> We are using SREGS but if required we can use one_reg.
> >>> I thought we were preferring one reg over sregs for new functionality.
> >> I'm personally torn on this one. The problem here is that the sregs
> >> fields and values are already reserved. For anything we don't have an
> >> API for yet, yes, one_reg only. IIUC we have the API here, but were
> >> lacking the implementation.
> >  From a QEMU perspective, are we going to want to update this at the same
> > time as everything else, or would jumping through sregs hoops be a
> > nuisance?  Is the long term goal to have one reg support for everything?
> 
> Because we need to maintain backwards compatibility, I don't think we'll 
> actually have any benefit from one reg support for everything.

We don't need to maintain backwards compatibility with interfaces that
were never implemented, and even where we do need to maintain
compatibility, that doesn't mean the caller needs to use the old,
cumbersome interface (don't assume the caller is QEMU, or that all new
features of QEMU need to support old kernels).

> I think we're in a path that is slow enough already to not worry about 
> performance.

It's not just about performance, but simplicity of use, and consistency
of API.

Oh, and it looks like there already exist one reg definitions and
implementations for most of the debug registers.

-Scott

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Scott Wood]

On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
> On 01.07.14 16:58, Scott Wood wrote:
> > On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
> >> I don't think QEMU should be aware of these limitations.
> > OK, but we should at least have some idea of how the whole thing is
> > supposed to work, in order to determine if this is the correct behavior
> > for QEMU.  I thought the model was that debug resources are either owned
> > by QEMU or by the guest, and in the latter case, QEMU would never see
> > the debug exception to begin with.
> 
> That's bad for a number of reasons. For starters it's different from how 
> x86 handles debug registers - and I hate to be different just for the 
> sake of being different.

How does it work on x86?

> So if we do want to declare that debug registers are owned by either
> QEMU or the guest, we should change the semantics for all
> architectures.

If we want to say that ownership of the registers is shared, we need a
plan for how that would actually work.

> The second problem I see is that we're disabling use cases for the sake 
> of correctness. When I use gdbstub, I usually don't want anything in the 
> way of debugging something - like if I want to debug the guest debugging 
> itself for example.

I don't have a problem with making it possible for userspace to forcibly
claim ownership of the debug registers -- but I don't want to advertise
that won't mess up the guest debugging that you're trying to debug,
without some reason to believe that.

> So overall, I think the x86 approach is a nice middle ground between 
> usability, performance and functionality.

You mean don't document anything other than the mechanism to get/set the
registers and hope everything works out? :-)

> >>>>> one reg?
> >>>> We are using SREGS but if required we can use one_reg.
> >>> I thought we were preferring one reg over sregs for new functionality.
> >> I'm personally torn on this one. The problem here is that the sregs
> >> fields and values are already reserved. For anything we don't have an
> >> API for yet, yes, one_reg only. IIUC we have the API here, but were
> >> lacking the implementation.
> >  From a QEMU perspective, are we going to want to update this at the same
> > time as everything else, or would jumping through sregs hoops be a
> > nuisance?  Is the long term goal to have one reg support for everything?
> 
> Because we need to maintain backwards compatibility, I don't think we'll 
> actually have any benefit from one reg support for everything.

We don't need to maintain backwards compatibility with interfaces that
were never implemented, and even where we do need to maintain
compatibility, that doesn't mean the caller needs to use the old,
cumbersome interface (don't assume the caller is QEMU, or that all new
features of QEMU need to support old kernels).

> I think we're in a path that is slow enough already to not worry about 
> performance.

It's not just about performance, but simplicity of use, and consistency
of API.

Oh, and it looks like there already exist one reg definitions and
implementations for most of the debug registers.

-Scott

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

On 01.07.14 17:35, Scott Wood wrote:
> On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
>> On 01.07.14 16:58, Scott Wood wrote:
>>> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
>>>> I don't think QEMU should be aware of these limitations.
>>> OK, but we should at least have some idea of how the whole thing is
>>> supposed to work, in order to determine if this is the correct behavior
>>> for QEMU.  I thought the model was that debug resources are either owned
>>> by QEMU or by the guest, and in the latter case, QEMU would never see
>>> the debug exception to begin with.
>> That's bad for a number of reasons. For starters it's different from how
>> x86 handles debug registers - and I hate to be different just for the
>> sake of being different.
> How does it work on x86?

It overwrites more-or-less random breakpoints with its own ones, but 
leaves the others intact ;).

>
>> So if we do want to declare that debug registers are owned by either
>> QEMU or the guest, we should change the semantics for all
>> architectures.
> If we want to say that ownership of the registers is shared, we need a
> plan for how that would actually work.

I think you're overengineering here :). When do people actually use 
gdbstub? Usually when they want to debug a broken guest. We can either

   * overengineer heavily and reduce the number of registers available 
to the guest to always have spares
   * overengineer a bit and turn off guest debugging completely when we 
use gdbstub
   * just leave as much alive as we can, hoping that it helps with the 
debugging

Option 3 is what x86 does - and I think it's a reasonable approach. This 
is not an interface that needs to be 100% consistent and bullet proof, 
it's a best effort to enable you to debug as much as possible.

>
>> The second problem I see is that we're disabling use cases for the sake
>> of correctness. When I use gdbstub, I usually don't want anything in the
>> way of debugging something - like if I want to debug the guest debugging
>> itself for example.
> I don't have a problem with making it possible for userspace to forcibly
> claim ownership of the debug registers -- but I don't want to advertise
> that won't mess up the guest debugging that you're trying to debug,
> without some reason to believe that.

It will mes up guest debugging, but only up to the extent that's 
necessary. We can even try to find unused breakpoint registers before we 
start killing guest ones.

>
>> So overall, I think the x86 approach is a nice middle ground between
>> usability, performance and functionality.
> You mean don't document anything other than the mechanism to get/set the
> registers and hope everything works out? :-)

There's certainly some lack of documentation here ;). Otherwise we 
probably wouldn't have this conversation :).

>
>>>>>>> one reg?
>>>>>> We are using SREGS but if required we can use one_reg.
>>>>> I thought we were preferring one reg over sregs for new functionality.
>>>> I'm personally torn on this one. The problem here is that the sregs
>>>> fields and values are already reserved. For anything we don't have an
>>>> API for yet, yes, one_reg only. IIUC we have the API here, but were
>>>> lacking the implementation.
>>>   From a QEMU perspective, are we going to want to update this at the same
>>> time as everything else, or would jumping through sregs hoops be a
>>> nuisance?  Is the long term goal to have one reg support for everything?
>> Because we need to maintain backwards compatibility, I don't think we'll
>> actually have any benefit from one reg support for everything.
> We don't need to maintain backwards compatibility with interfaces that
> were never implemented, and even where we do need to maintain
> compatibility, that doesn't mean the caller needs to use the old,
> cumbersome interface (don't assume the caller is QEMU, or that all new
> features of QEMU need to support old kernels).

Yes, that's why I'm torn for this particular case. I thought you were 
asking about the general line of thinking. In this concrete case I think 
the only thing we get from using SREGS over ONE_REG is that we don't 
have to wait for the patches to trickle into kvm-next to be able to 
apply the QEMU patches ;).

 From an esthetic point of view, I would prefer ONE_REG too.

>
>> I think we're in a path that is slow enough already to not worry about
>> performance.
> It's not just about performance, but simplicity of use, and consistency
> of API.
>
> Oh, and it looks like there already exist one reg definitions and
> implementations for most of the debug registers.

For BookE? Where?


Alex

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

On 01.07.14 17:35, Scott Wood wrote:
> On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
>> On 01.07.14 16:58, Scott Wood wrote:
>>> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
>>>> I don't think QEMU should be aware of these limitations.
>>> OK, but we should at least have some idea of how the whole thing is
>>> supposed to work, in order to determine if this is the correct behavior
>>> for QEMU.  I thought the model was that debug resources are either owned
>>> by QEMU or by the guest, and in the latter case, QEMU would never see
>>> the debug exception to begin with.
>> That's bad for a number of reasons. For starters it's different from how
>> x86 handles debug registers - and I hate to be different just for the
>> sake of being different.
> How does it work on x86?

It overwrites more-or-less random breakpoints with its own ones, but 
leaves the others intact ;).

>
>> So if we do want to declare that debug registers are owned by either
>> QEMU or the guest, we should change the semantics for all
>> architectures.
> If we want to say that ownership of the registers is shared, we need a
> plan for how that would actually work.

I think you're overengineering here :). When do people actually use 
gdbstub? Usually when they want to debug a broken guest. We can either

   * overengineer heavily and reduce the number of registers available 
to the guest to always have spares
   * overengineer a bit and turn off guest debugging completely when we 
use gdbstub
   * just leave as much alive as we can, hoping that it helps with the 
debugging

Option 3 is what x86 does - and I think it's a reasonable approach. This 
is not an interface that needs to be 100% consistent and bullet proof, 
it's a best effort to enable you to debug as much as possible.

>
>> The second problem I see is that we're disabling use cases for the sake
>> of correctness. When I use gdbstub, I usually don't want anything in the
>> way of debugging something - like if I want to debug the guest debugging
>> itself for example.
> I don't have a problem with making it possible for userspace to forcibly
> claim ownership of the debug registers -- but I don't want to advertise
> that won't mess up the guest debugging that you're trying to debug,
> without some reason to believe that.

It will mes up guest debugging, but only up to the extent that's 
necessary. We can even try to find unused breakpoint registers before we 
start killing guest ones.

>
>> So overall, I think the x86 approach is a nice middle ground between
>> usability, performance and functionality.
> You mean don't document anything other than the mechanism to get/set the
> registers and hope everything works out? :-)

There's certainly some lack of documentation here ;). Otherwise we 
probably wouldn't have this conversation :).

>
>>>>>>> one reg?
>>>>>> We are using SREGS but if required we can use one_reg.
>>>>> I thought we were preferring one reg over sregs for new functionality.
>>>> I'm personally torn on this one. The problem here is that the sregs
>>>> fields and values are already reserved. For anything we don't have an
>>>> API for yet, yes, one_reg only. IIUC we have the API here, but were
>>>> lacking the implementation.
>>>   From a QEMU perspective, are we going to want to update this at the same
>>> time as everything else, or would jumping through sregs hoops be a
>>> nuisance?  Is the long term goal to have one reg support for everything?
>> Because we need to maintain backwards compatibility, I don't think we'll
>> actually have any benefit from one reg support for everything.
> We don't need to maintain backwards compatibility with interfaces that
> were never implemented, and even where we do need to maintain
> compatibility, that doesn't mean the caller needs to use the old,
> cumbersome interface (don't assume the caller is QEMU, or that all new
> features of QEMU need to support old kernels).

Yes, that's why I'm torn for this particular case. I thought you were 
asking about the general line of thinking. In this concrete case I think 
the only thing we get from using SREGS over ONE_REG is that we don't 
have to wait for the patches to trickle into kvm-next to be able to 
apply the QEMU patches ;).

 From an esthetic point of view, I would prefer ONE_REG too.

>
>> I think we're in a path that is slow enough already to not worry about
>> performance.
> It's not just about performance, but simplicity of use, and consistency
> of API.
>
> Oh, and it looks like there already exist one reg definitions and
> implementations for most of the debug registers.

For BookE? Where?


Alex

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Scott Wood]

On Tue, 2014-07-01 at 18:22 +0200, Alexander Graf wrote:
> On 01.07.14 17:35, Scott Wood wrote:
> > On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
> >> On 01.07.14 16:58, Scott Wood wrote:
> >>> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
> >>>> I don't think QEMU should be aware of these limitations.
> >>> OK, but we should at least have some idea of how the whole thing is
> >>> supposed to work, in order to determine if this is the correct behavior
> >>> for QEMU.  I thought the model was that debug resources are either owned
> >>> by QEMU or by the guest, and in the latter case, QEMU would never see
> >>> the debug exception to begin with.
> >> That's bad for a number of reasons. For starters it's different from how
> >> x86 handles debug registers - and I hate to be different just for the
> >> sake of being different.
> > How does it work on x86?
> 
> It overwrites more-or-less random breakpoints with its own ones, but 
> leaves the others intact ;).

Are you talking about software breakpoints or management of hardware
debug registers?

> >> So if we do want to declare that debug registers are owned by either
> >> QEMU or the guest, we should change the semantics for all
> >> architectures.
> > If we want to say that ownership of the registers is shared, we need a
> > plan for how that would actually work.
> 
> I think you're overengineering here :). When do people actually use 
> gdbstub? Usually when they want to debug a broken guest. We can either
> 
>    * overengineer heavily and reduce the number of registers available 
> to the guest to always have spares
>    * overengineer a bit and turn off guest debugging completely when we 
> use gdbstub
>    * just leave as much alive as we can, hoping that it helps with the 
> debugging
> 
> Option 3 is what x86 does - and I think it's a reasonable approach. This 
> is not an interface that needs to be 100% consistent and bullet proof, 
> it's a best effort to enable you to debug as much as possible.

I'm not insisting on 100% -- just hoping for some explanation/discussion
about how it's intended to work for the cases where it can.

How will MSR[DE] and MSRP[DEP] be handled?

How would I go about telling QEMU/KVM that I don't want this shared
mode, because I don't want guest to interfere with the debugging I'm
trying to do from QEMU?

Will guest accesses to debug registers cause a userspace exit when
guest_debug is enabled?

> >> I think we're in a path that is slow enough already to not worry about
> >> performance.
> > It's not just about performance, but simplicity of use, and consistency
> > of API.
> >
> > Oh, and it looks like there already exist one reg definitions and
> > implementations for most of the debug registers.
> 
> For BookE? Where?

arch/powerpc/kvm/booke.c: KVM_REG_PPC_IACn, KVM_REG_PPC_DACn

-Scott

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Scott Wood]

On Tue, 2014-07-01 at 18:22 +0200, Alexander Graf wrote:
> On 01.07.14 17:35, Scott Wood wrote:
> > On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
> >> On 01.07.14 16:58, Scott Wood wrote:
> >>> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
> >>>> I don't think QEMU should be aware of these limitations.
> >>> OK, but we should at least have some idea of how the whole thing is
> >>> supposed to work, in order to determine if this is the correct behavior
> >>> for QEMU.  I thought the model was that debug resources are either owned
> >>> by QEMU or by the guest, and in the latter case, QEMU would never see
> >>> the debug exception to begin with.
> >> That's bad for a number of reasons. For starters it's different from how
> >> x86 handles debug registers - and I hate to be different just for the
> >> sake of being different.
> > How does it work on x86?
> 
> It overwrites more-or-less random breakpoints with its own ones, but 
> leaves the others intact ;).

Are you talking about software breakpoints or management of hardware
debug registers?

> >> So if we do want to declare that debug registers are owned by either
> >> QEMU or the guest, we should change the semantics for all
> >> architectures.
> > If we want to say that ownership of the registers is shared, we need a
> > plan for how that would actually work.
> 
> I think you're overengineering here :). When do people actually use 
> gdbstub? Usually when they want to debug a broken guest. We can either
> 
>    * overengineer heavily and reduce the number of registers available 
> to the guest to always have spares
>    * overengineer a bit and turn off guest debugging completely when we 
> use gdbstub
>    * just leave as much alive as we can, hoping that it helps with the 
> debugging
> 
> Option 3 is what x86 does - and I think it's a reasonable approach. This 
> is not an interface that needs to be 100% consistent and bullet proof, 
> it's a best effort to enable you to debug as much as possible.

I'm not insisting on 100% -- just hoping for some explanation/discussion
about how it's intended to work for the cases where it can.

How will MSR[DE] and MSRP[DEP] be handled?

How would I go about telling QEMU/KVM that I don't want this shared
mode, because I don't want guest to interfere with the debugging I'm
trying to do from QEMU?

Will guest accesses to debug registers cause a userspace exit when
guest_debug is enabled?

> >> I think we're in a path that is slow enough already to not worry about
> >> performance.
> > It's not just about performance, but simplicity of use, and consistency
> > of API.
> >
> > Oh, and it looks like there already exist one reg definitions and
> > implementations for most of the debug registers.
> 
> For BookE? Where?

arch/powerpc/kvm/booke.c: KVM_REG_PPC_IACn, KVM_REG_PPC_DACn

-Scott

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, July 01, 2014 10:11 PM
> To: Alexander Graf
> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> guest
> 
> On Tue, 2014-07-01 at 18:22 +0200, Alexander Graf wrote:
> > On 01.07.14 17:35, Scott Wood wrote:
> > > On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
> > >> On 01.07.14 16:58, Scott Wood wrote:
> > >>> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
> > >>>> I don't think QEMU should be aware of these limitations.
> > >>> OK, but we should at least have some idea of how the whole thing
> > >>> is supposed to work, in order to determine if this is the correct
> > >>> behavior for QEMU.  I thought the model was that debug resources
> > >>> are either owned by QEMU or by the guest, and in the latter case,
> > >>> QEMU would never see the debug exception to begin with.
> > >> That's bad for a number of reasons. For starters it's different
> > >> from how
> > >> x86 handles debug registers - and I hate to be different just for
> > >> the sake of being different.
> > > How does it work on x86?
> >
> > It overwrites more-or-less random breakpoints with its own ones, but
> > leaves the others intact ;).
> 
> Are you talking about software breakpoints or management of hardware debug
> registers?
> 
> > >> So if we do want to declare that debug registers are owned by
> > >> either QEMU or the guest, we should change the semantics for all
> > >> architectures.
> > > If we want to say that ownership of the registers is shared, we need
> > > a plan for how that would actually work.
> >
> > I think you're overengineering here :). When do people actually use
> > gdbstub? Usually when they want to debug a broken guest. We can either
> >
> >    * overengineer heavily and reduce the number of registers available
> > to the guest to always have spares
> >    * overengineer a bit and turn off guest debugging completely when
> > we use gdbstub
> >    * just leave as much alive as we can, hoping that it helps with the
> > debugging
> >
> > Option 3 is what x86 does - and I think it's a reasonable approach.
> > This is not an interface that needs to be 100% consistent and bullet
> > proof, it's a best effort to enable you to debug as much as possible.
> 
> I'm not insisting on 100% -- just hoping for some explanation/discussion about
> how it's intended to work for the cases where it can.
> 
> How will MSR[DE] and MSRP[DEP] be handled?
> 
> How would I go about telling QEMU/KVM that I don't want this shared mode,
> because I don't want guest to interfere with the debugging I'm trying to do from
> QEMU?
> 
> Will guest accesses to debug registers cause a userspace exit when guest_debug
> is enabled?
> 
> > >> I think we're in a path that is slow enough already to not worry
> > >> about performance.
> > > It's not just about performance, but simplicity of use, and
> > > consistency of API.
> > >
> > > Oh, and it looks like there already exist one reg definitions and
> > > implementations for most of the debug registers.
> >
> > For BookE? Where?
> 
> arch/powerpc/kvm/booke.c: KVM_REG_PPC_IACn, KVM_REG_PPC_DACn

I tried to quickly prototype what I think we want to do (this is not tested)

-----------------------------------------------------------------------
diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
index e8b3982..746b5c6 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -179,6 +179,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);
+
 /*
  * Cuts out inst bits with ordering according to spec.
  * That means the leftmost bit is zero. All given bits are included.
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 9f13056..0b7e4e4 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -235,6 +235,16 @@ void kvmppc_core_dequeue_dec(struct kvm_vcpu *vcpu)
 	clear_bit(BOOKE_IRQPRIO_DECREMENTER, &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);
+}
+
 void kvmppc_core_queue_external(struct kvm_vcpu *vcpu,
                                 struct kvm_interrupt *irq)
 {
@@ -841,6 +851,20 @@ 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;
 
+	/* Userspace (QEMU) is not using debug resource, so inject debug interrupt
+	 * directly to guest debug.
+	 */
+	if (vcpu->guest_debug == 0) {
+		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;
+	}
+
 	run->debug.arch.status = 0;
 	run->debug.arch.address = vcpu->arch.pc;
 
@@ -1920,7 +1944,7 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
 	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;
+//	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
 
 	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
 		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC;
diff --git a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
index aaff1b7..ef8de7f 100644
--- a/arch/powerpc/kvm/booke_emulate.c
+++ b/arch/powerpc/kvm/booke_emulate.c
@@ -26,6 +26,7 @@
 #define OP_19_XOP_RFMCI   38
 #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
@@ -38,10 +39,24 @@ 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;
-	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);
 }
 
 static void kvmppc_emul_rfmci(struct kvm_vcpu *vcpu)
@@ -78,6 +93,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;
@@ -131,6 +152,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:
@@ -145,21 +167,74 @@ 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_DBCR0:
-		vcpu->arch.dbg_reg.dbcr0 = spr_val;
+	case SPRN_DSRR0:
+		vcpu->arch.dsrr0 = spr_val;
 		break;
-	case SPRN_DBCR1:
-		vcpu->arch.dbg_reg.dbcr1 = spr_val;
+	case SPRN_DSRR1:
+		vcpu->arch.dsrr1 = spr_val;
+		break;
+	case SPRN_IAC1:
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac1 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac1 = spr_val;
+		break;
+	case SPRN_IAC2:
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac2 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac2 = spr_val;
+		break;
+#ifndef CONFIG_PPC_FSL_BOOK3E
+	case SPRN_IAC3:
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac3 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac3 = spr_val;
 		break;
+	case SPRN_IAC4:
+		debug_inst = true;
+		vcpu->arch.dbg_reg.iac4 = spr_val;
+		vcpu->arch.shadow_dbg_reg.iac4 = spr_val;
+		break;
+#endif
+	case SPRN_DAC1:
+		debug_inst = true;
+		vcpu->arch.dbg_reg.dac1 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dac1 = spr_val;
+		break;
+	case SPRN_DAC2:
+		debug_inst = true;
+		vcpu->arch.dbg_reg.dac2 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dac2 = spr_val;
+		break;
+ 	case SPRN_DBCR0:
+		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:
+		debug_inst = true;
+ 		vcpu->arch.dbg_reg.dbcr1 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dbcr1 = spr_val;
+		break;
+	case SPRN_DBCR2:
+		debug_inst = true;
+		vcpu->arch.dbg_reg.dbcr2 = spr_val;
+		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
+ 		break;
+ 	case SPRN_DBSR:
+ 		vcpu->arch.dbsr &= ~spr_val;
+		if (vcpu->arch.dbsr == 0)
+			kvmppc_core_dequeue_debug(vcpu);
+ 		break;
 	case SPRN_MCSRR0:
 		vcpu->arch.mcsrr0 = spr_val;
 		break;
 	case SPRN_MCSRR1:
 		vcpu->arch.mcsrr1 = spr_val;
 		break;
-	case SPRN_DBSR:
-		vcpu->arch.dbsr &= ~spr_val;
-		break;
 	case SPRN_TSR:
 		kvmppc_clr_tsr_bits(vcpu, spr_val);
 		break;
@@ -271,6 +346,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;
 }
 
@@ -297,12 +376,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;
+#ifndef CONFIG_PPC_FSL_BOOK3E
+	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_MCSRR0:
 		*spr_val = vcpu->arch.mcsrr0;
 		break;
diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
index bbf7cdd..560b576 100644
--- a/arch/powerpc/kvm/e500mc.c
+++ b/arch/powerpc/kvm/e500mc.c
@@ -249,7 +249,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.pvr = mfspr(SPRN_PVR);
 	vcpu_e500->svr = mfspr(SPRN_SVR);


------------------

Thanks
-Bharat

> 
> -Scott
> 

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdvb2QgU2NvdHQtQjA3NDIx
DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDEsIDIwMTQgMTA6MTEgUE0NCj4gVG86IEFsZXhhbmRl
ciBHcmFmDQo+IENjOiBCaHVzaGFuIEJoYXJhdC1SNjU3Nzc7IGt2bS1wcGNAdmdlci5rZXJuZWwu
b3JnOyBrdm1Admdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi8yXSBLVk0g
OiBwb3dlcnBjL2Jvb2tlOiBBbGxvdyBkZWJ1ZyBpbnRlcnJ1cHQgaW5qZWN0aW9uIHRvDQo+IGd1
ZXN0DQo+IA0KPiBPbiBUdWUsIDIwMTQtMDctMDEgYXQgMTg6MjIgKzAyMDAsIEFsZXhhbmRlciBH
cmFmIHdyb3RlOg0KPiA+IE9uIDAxLjA3LjE0IDE3OjM1LCBTY290dCBXb29kIHdyb3RlOg0KPiA+
ID4gT24gVHVlLCAyMDE0LTA3LTAxIGF0IDE3OjA0ICswMjAwLCBBbGV4YW5kZXIgR3JhZiB3cm90
ZToNCj4gPiA+PiBPbiAwMS4wNy4xNCAxNjo1OCwgU2NvdHQgV29vZCB3cm90ZToNCj4gPiA+Pj4g
T24gVHVlLCAyMDE0LTA3LTAxIGF0IDA4OjIzICswMjAwLCBBbGV4YW5kZXIgR3JhZiB3cm90ZToN
Cj4gPiA+Pj4+IEkgZG9uJ3QgdGhpbmsgUUVNVSBzaG91bGQgYmUgYXdhcmUgb2YgdGhlc2UgbGlt
aXRhdGlvbnMuDQo+ID4gPj4+IE9LLCBidXQgd2Ugc2hvdWxkIGF0IGxlYXN0IGhhdmUgc29tZSBp
ZGVhIG9mIGhvdyB0aGUgd2hvbGUgdGhpbmcNCj4gPiA+Pj4gaXMgc3VwcG9zZWQgdG8gd29yaywg
aW4gb3JkZXIgdG8gZGV0ZXJtaW5lIGlmIHRoaXMgaXMgdGhlIGNvcnJlY3QNCj4gPiA+Pj4gYmVo
YXZpb3IgZm9yIFFFTVUuICBJIHRob3VnaHQgdGhlIG1vZGVsIHdhcyB0aGF0IGRlYnVnIHJlc291
cmNlcw0KPiA+ID4+PiBhcmUgZWl0aGVyIG93bmVkIGJ5IFFFTVUgb3IgYnkgdGhlIGd1ZXN0LCBh
bmQgaW4gdGhlIGxhdHRlciBjYXNlLA0KPiA+ID4+PiBRRU1VIHdvdWxkIG5ldmVyIHNlZSB0aGUg
ZGVidWcgZXhjZXB0aW9uIHRvIGJlZ2luIHdpdGguDQo+ID4gPj4gVGhhdCdzIGJhZCBmb3IgYSBu
dW1iZXIgb2YgcmVhc29ucy4gRm9yIHN0YXJ0ZXJzIGl0J3MgZGlmZmVyZW50DQo+ID4gPj4gZnJv
bSBob3cNCj4gPiA+PiB4ODYgaGFuZGxlcyBkZWJ1ZyByZWdpc3RlcnMgLSBhbmQgSSBoYXRlIHRv
IGJlIGRpZmZlcmVudCBqdXN0IGZvcg0KPiA+ID4+IHRoZSBzYWtlIG9mIGJlaW5nIGRpZmZlcmVu
dC4NCj4gPiA+IEhvdyBkb2VzIGl0IHdvcmsgb24geDg2Pw0KPiA+DQo+ID4gSXQgb3ZlcndyaXRl
cyBtb3JlLW9yLWxlc3MgcmFuZG9tIGJyZWFrcG9pbnRzIHdpdGggaXRzIG93biBvbmVzLCBidXQN
Cj4gPiBsZWF2ZXMgdGhlIG90aGVycyBpbnRhY3QgOykuDQo+IA0KPiBBcmUgeW91IHRhbGtpbmcg
YWJvdXQgc29mdHdhcmUgYnJlYWtwb2ludHMgb3IgbWFuYWdlbWVudCBvZiBoYXJkd2FyZSBkZWJ1
Zw0KPiByZWdpc3RlcnM/DQo+IA0KPiA+ID4+IFNvIGlmIHdlIGRvIHdhbnQgdG8gZGVjbGFyZSB0
aGF0IGRlYnVnIHJlZ2lzdGVycyBhcmUgb3duZWQgYnkNCj4gPiA+PiBlaXRoZXIgUUVNVSBvciB0
aGUgZ3Vlc3QsIHdlIHNob3VsZCBjaGFuZ2UgdGhlIHNlbWFudGljcyBmb3IgYWxsDQo+ID4gPj4g
YXJjaGl0ZWN0dXJlcy4NCj4gPiA+IElmIHdlIHdhbnQgdG8gc2F5IHRoYXQgb3duZXJzaGlwIG9m
IHRoZSByZWdpc3RlcnMgaXMgc2hhcmVkLCB3ZSBuZWVkDQo+ID4gPiBhIHBsYW4gZm9yIGhvdyB0
aGF0IHdvdWxkIGFjdHVhbGx5IHdvcmsuDQo+ID4NCj4gPiBJIHRoaW5rIHlvdSdyZSBvdmVyZW5n
aW5lZXJpbmcgaGVyZSA6KS4gV2hlbiBkbyBwZW9wbGUgYWN0dWFsbHkgdXNlDQo+ID4gZ2Ric3R1
Yj8gVXN1YWxseSB3aGVuIHRoZXkgd2FudCB0byBkZWJ1ZyBhIGJyb2tlbiBndWVzdC4gV2UgY2Fu
IGVpdGhlcg0KPiA+DQo+ID4gICAgKiBvdmVyZW5naW5lZXIgaGVhdmlseSBhbmQgcmVkdWNlIHRo
ZSBudW1iZXIgb2YgcmVnaXN0ZXJzIGF2YWlsYWJsZQ0KPiA+IHRvIHRoZSBndWVzdCB0byBhbHdh
eXMgaGF2ZSBzcGFyZXMNCj4gPiAgICAqIG92ZXJlbmdpbmVlciBhIGJpdCBhbmQgdHVybiBvZmYg
Z3Vlc3QgZGVidWdnaW5nIGNvbXBsZXRlbHkgd2hlbg0KPiA+IHdlIHVzZSBnZGJzdHViDQo+ID4g
ICAgKiBqdXN0IGxlYXZlIGFzIG11Y2ggYWxpdmUgYXMgd2UgY2FuLCBob3BpbmcgdGhhdCBpdCBo
ZWxwcyB3aXRoIHRoZQ0KPiA+IGRlYnVnZ2luZw0KPiA+DQo+ID4gT3B0aW9uIDMgaXMgd2hhdCB4
ODYgZG9lcyAtIGFuZCBJIHRoaW5rIGl0J3MgYSByZWFzb25hYmxlIGFwcHJvYWNoLg0KPiA+IFRo
aXMgaXMgbm90IGFuIGludGVyZmFjZSB0aGF0IG5lZWRzIHRvIGJlIDEwMCUgY29uc2lzdGVudCBh
bmQgYnVsbGV0DQo+ID4gcHJvb2YsIGl0J3MgYSBiZXN0IGVmZm9ydCB0byBlbmFibGUgeW91IHRv
IGRlYnVnIGFzIG11Y2ggYXMgcG9zc2libGUuDQo+IA0KPiBJJ20gbm90IGluc2lzdGluZyBvbiAx
MDAlIC0tIGp1c3QgaG9waW5nIGZvciBzb21lIGV4cGxhbmF0aW9uL2Rpc2N1c3Npb24gYWJvdXQN
Cj4gaG93IGl0J3MgaW50ZW5kZWQgdG8gd29yayBmb3IgdGhlIGNhc2VzIHdoZXJlIGl0IGNhbi4N
Cj4gDQo+IEhvdyB3aWxsIE1TUltERV0gYW5kIE1TUlBbREVQXSBiZSBoYW5kbGVkPw0KPiANCj4g
SG93IHdvdWxkIEkgZ28gYWJvdXQgdGVsbGluZyBRRU1VL0tWTSB0aGF0IEkgZG9uJ3Qgd2FudCB0
aGlzIHNoYXJlZCBtb2RlLA0KPiBiZWNhdXNlIEkgZG9uJ3Qgd2FudCBndWVzdCB0byBpbnRlcmZl
cmUgd2l0aCB0aGUgZGVidWdnaW5nIEknbSB0cnlpbmcgdG8gZG8gZnJvbQ0KPiBRRU1VPw0KPiAN
Cj4gV2lsbCBndWVzdCBhY2Nlc3NlcyB0byBkZWJ1ZyByZWdpc3RlcnMgY2F1c2UgYSB1c2Vyc3Bh
Y2UgZXhpdCB3aGVuIGd1ZXN0X2RlYnVnDQo+IGlzIGVuYWJsZWQ/DQo+IA0KPiA+ID4+IEkgdGhp
bmsgd2UncmUgaW4gYSBwYXRoIHRoYXQgaXMgc2xvdyBlbm91Z2ggYWxyZWFkeSB0byBub3Qgd29y
cnkNCj4gPiA+PiBhYm91dCBwZXJmb3JtYW5jZS4NCj4gPiA+IEl0J3Mgbm90IGp1c3QgYWJvdXQg
cGVyZm9ybWFuY2UsIGJ1dCBzaW1wbGljaXR5IG9mIHVzZSwgYW5kDQo+ID4gPiBjb25zaXN0ZW5j
eSBvZiBBUEkuDQo+ID4gPg0KPiA+ID4gT2gsIGFuZCBpdCBsb29rcyBsaWtlIHRoZXJlIGFscmVh
ZHkgZXhpc3Qgb25lIHJlZyBkZWZpbml0aW9ucyBhbmQNCj4gPiA+IGltcGxlbWVudGF0aW9ucyBm
b3IgbW9zdCBvZiB0aGUgZGVidWcgcmVnaXN0ZXJzLg0KPiA+DQo+ID4gRm9yIEJvb2tFPyBXaGVy
ZT8NCj4gDQo+IGFyY2gvcG93ZXJwYy9rdm0vYm9va2UuYzogS1ZNX1JFR19QUENfSUFDbiwgS1ZN
X1JFR19QUENfREFDbg0KDQpJIHRyaWVkIHRvIHF1aWNrbHkgcHJvdG90eXBlIHdoYXQgSSB0aGlu
ayB3ZSB3YW50IHRvIGRvICh0aGlzIGlzIG5vdCB0ZXN0ZWQpDQoNCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpk
aWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL2luY2x1ZGUvYXNtL2t2bV9wcGMuaCBiL2FyY2gvcG93
ZXJwYy9pbmNsdWRlL2FzbS9rdm1fcHBjLmgNCmluZGV4IGU4YjM5ODIuLjc0NmI1YzYgMTAwNjQ0
DQotLS0gYS9hcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20va3ZtX3BwYy5oDQorKysgYi9hcmNoL3Bv
d2VycGMvaW5jbHVkZS9hc20va3ZtX3BwYy5oDQpAQCAtMTc5LDYgKzE3OSw5IEBAIGV4dGVybiBp
bnQga3ZtcHBjX3hpY3NfZ2V0X3hpdmUoc3RydWN0IGt2bSAqa3ZtLCB1MzIgaXJxLCB1MzIgKnNl
cnZlciwNCiBleHRlcm4gaW50IGt2bXBwY194aWNzX2ludF9vbihzdHJ1Y3Qga3ZtICprdm0sIHUz
MiBpcnEpOw0KIGV4dGVybiBpbnQga3ZtcHBjX3hpY3NfaW50X29mZihzdHJ1Y3Qga3ZtICprdm0s
IHUzMiBpcnEpOw0KIA0KK3ZvaWQga3ZtcHBjX2NvcmVfZGVxdWV1ZV9kZWJ1ZyhzdHJ1Y3Qga3Zt
X3ZjcHUgKnZjcHUpOw0KK3ZvaWQga3ZtcHBjX2NvcmVfcXVldWVfZGVidWcoc3RydWN0IGt2bV92
Y3B1ICp2Y3B1KTsNCisNCiAvKg0KICAqIEN1dHMgb3V0IGluc3QgYml0cyB3aXRoIG9yZGVyaW5n
IGFjY29yZGluZyB0byBzcGVjLg0KICAqIFRoYXQgbWVhbnMgdGhlIGxlZnRtb3N0IGJpdCBpcyB6
ZXJvLiBBbGwgZ2l2ZW4gYml0cyBhcmUgaW5jbHVkZWQuDQpkaWZmIC0tZ2l0IGEvYXJjaC9wb3dl
cnBjL2t2bS9ib29rZS5jIGIvYXJjaC9wb3dlcnBjL2t2bS9ib29rZS5jDQppbmRleCA5ZjEzMDU2
Li4wYjdlNGU0IDEwMDY0NA0KLS0tIGEvYXJjaC9wb3dlcnBjL2t2bS9ib29rZS5jDQorKysgYi9h
cmNoL3Bvd2VycGMva3ZtL2Jvb2tlLmMNCkBAIC0yMzUsNiArMjM1LDE2IEBAIHZvaWQga3ZtcHBj
X2NvcmVfZGVxdWV1ZV9kZWMoc3RydWN0IGt2bV92Y3B1ICp2Y3B1KQ0KIAljbGVhcl9iaXQoQk9P
S0VfSVJRUFJJT19ERUNSRU1FTlRFUiwgJnZjcHUtPmFyY2gucGVuZGluZ19leGNlcHRpb25zKTsN
CiB9DQogDQordm9pZCBrdm1wcGNfY29yZV9xdWV1ZV9kZWJ1ZyhzdHJ1Y3Qga3ZtX3ZjcHUgKnZj
cHUpDQorew0KKwlrdm1wcGNfYm9va2VfcXVldWVfaXJxcHJpbyh2Y3B1LCBCT09LRV9JUlFQUklP
X0RFQlVHKTsNCit9DQorIA0KK3ZvaWQga3ZtcHBjX2NvcmVfZGVxdWV1ZV9kZWJ1ZyhzdHJ1Y3Qg
a3ZtX3ZjcHUgKnZjcHUpDQorew0KKwljbGVhcl9iaXQoQk9PS0VfSVJRUFJJT19ERUJVRywgJnZj
cHUtPmFyY2gucGVuZGluZ19leGNlcHRpb25zKTsNCit9DQorDQogdm9pZCBrdm1wcGNfY29yZV9x
dWV1ZV9leHRlcm5hbChzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUsDQogICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBzdHJ1Y3Qga3ZtX2ludGVycnVwdCAqaXJxKQ0KIHsNCkBAIC04NDEsNiAr
ODUxLDIwIEBAIHN0YXRpYyBpbnQga3ZtcHBjX2hhbmRsZV9kZWJ1ZyhzdHJ1Y3Qga3ZtX3J1biAq
cnVuLCBzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUpDQogCXN0cnVjdCBkZWJ1Z19yZWcgKmRiZ19yZWcg
PSAmKHZjcHUtPmFyY2guc2hhZG93X2RiZ19yZWcpOw0KIAl1MzIgZGJzciA9IHZjcHUtPmFyY2gu
ZGJzcjsNCiANCisJLyogVXNlcnNwYWNlIChRRU1VKSBpcyBub3QgdXNpbmcgZGVidWcgcmVzb3Vy
Y2UsIHNvIGluamVjdCBkZWJ1ZyBpbnRlcnJ1cHQNCisJICogZGlyZWN0bHkgdG8gZ3Vlc3QgZGVi
dWcuDQorCSAqLw0KKwlpZiAodmNwdS0+Z3Vlc3RfZGVidWcgPT0gMCkgew0KKwkJaWYgKGRic3Ig
JiYgKHZjcHUtPmFyY2guc2hhcmVkLT5tc3IgJiBNU1JfREUpKQ0KKwkJCWt2bXBwY19jb3JlX3F1
ZXVlX2RlYnVnKHZjcHUpOw0KKw0KKwkJLyogSW5qZWN0IGEgcHJvZ3JhbSBpbnRlcnJ1cHQgaWYg
dHJhcCBkZWJ1ZyBpcyBub3QgYWxsb3dlZCAqLw0KKwkJaWYgKChkYnNyICYgREJTUl9USUUpICYm
ICEodmNwdS0+YXJjaC5zaGFyZWQtPm1zciAmIE1TUl9ERSkpDQorCQkJa3ZtcHBjX2NvcmVfcXVl
dWVfcHJvZ3JhbSh2Y3B1LCBFU1JfUFRSKTsNCisNCisJCXJldHVybiBSRVNVTUVfR1VFU1Q7DQor
CX0NCisNCiAJcnVuLT5kZWJ1Zy5hcmNoLnN0YXR1cyA9IDA7DQogCXJ1bi0+ZGVidWcuYXJjaC5h
ZGRyZXNzID0gdmNwdS0+YXJjaC5wYzsNCiANCkBAIC0xOTIwLDcgKzE5NDQsNyBAQCBpbnQga3Zt
X2FyY2hfdmNwdV9pb2N0bF9zZXRfZ3Vlc3RfZGVidWcoc3RydWN0IGt2bV92Y3B1ICp2Y3B1LA0K
IAl2Y3B1LT5ndWVzdF9kZWJ1ZyA9IGRiZy0+Y29udHJvbDsNCiAJdmNwdS0+YXJjaC5zaGFkb3df
ZGJnX3JlZy5kYmNyMCA9IDA7DQogCS8qIFNldCBEQkNSMF9FRE0gaW4gZ3Vlc3QgdmlzaWJsZSBE
QkNSMCByZWdpc3Rlci4gKi8NCi0JdmNwdS0+YXJjaC5kYmdfcmVnLmRiY3IwID0gREJDUjBfRURN
Ow0KKy8vCXZjcHUtPmFyY2guZGJnX3JlZy5kYmNyMCA9IERCQ1IwX0VETTsNCiANCiAJaWYgKHZj
cHUtPmd1ZXN0X2RlYnVnICYgS1ZNX0dVRVNUREJHX1NJTkdMRVNURVApDQogCQl2Y3B1LT5hcmNo
LnNoYWRvd19kYmdfcmVnLmRiY3IwIHw9IERCQ1IwX0lETSB8IERCQ1IwX0lDOw0KZGlmZiAtLWdp
dCBhL2FyY2gvcG93ZXJwYy9rdm0vYm9va2VfZW11bGF0ZS5jIGIvYXJjaC9wb3dlcnBjL2t2bS9i
b29rZV9lbXVsYXRlLmMNCmluZGV4IGFhZmYxYjcuLmVmOGRlN2YgMTAwNjQ0DQotLS0gYS9hcmNo
L3Bvd2VycGMva3ZtL2Jvb2tlX2VtdWxhdGUuYw0KKysrIGIvYXJjaC9wb3dlcnBjL2t2bS9ib29r
ZV9lbXVsYXRlLmMNCkBAIC0yNiw2ICsyNiw3IEBADQogI2RlZmluZSBPUF8xOV9YT1BfUkZNQ0kg
ICAzOA0KICNkZWZpbmUgT1BfMTlfWE9QX1JGSSAgICAgNTANCiAjZGVmaW5lIE9QXzE5X1hPUF9S
RkNJICAgIDUxDQorI2RlZmluZSBPUF8xOV9YT1BfUkZESSAgICAzOQ0KIA0KICNkZWZpbmUgT1Bf
MzFfWE9QX01GTVNSICAgODMNCiAjZGVmaW5lIE9QXzMxX1hPUF9XUlRFRSAgIDEzMQ0KQEAgLTM4
LDEwICszOSwyNCBAQCBzdGF0aWMgdm9pZCBrdm1wcGNfZW11bF9yZmkoc3RydWN0IGt2bV92Y3B1
ICp2Y3B1KQ0KIAlrdm1wcGNfc2V0X21zcih2Y3B1LCB2Y3B1LT5hcmNoLnNoYXJlZC0+c3JyMSk7
DQogfQ0KIA0KK3N0YXRpYyB2b2lkIGt2bXBwY19lbXVsX3JmZGkoc3RydWN0IGt2bV92Y3B1ICp2
Y3B1KQ0KK3sNCisJdmNwdS0+YXJjaC5wYyA9IHZjcHUtPmFyY2guZHNycjA7DQorCS8qIEZvcmNl
IE1TUl9ERSB3aGVuIGd1ZXN0IGRvZXMgbm90IG93biBkZWJ1ZyBmYWNpbGl0aWVzICovDQorCWlm
ICh2Y3B1LT5ndWVzdF9kZWJ1ZykNCisJCWt2bXBwY19zZXRfbXNyKHZjcHUsIHZjcHUtPmFyY2gu
ZHNycjEgfCBNU1JfREUpOw0KKwllbHNlDQorCQlrdm1wcGNfc2V0X21zcih2Y3B1LCB2Y3B1LT5h
cmNoLmRzcnIxKTsNCit9DQorDQogc3RhdGljIHZvaWQga3ZtcHBjX2VtdWxfcmZjaShzdHJ1Y3Qg
a3ZtX3ZjcHUgKnZjcHUpDQogew0KIAl2Y3B1LT5hcmNoLnBjID0gdmNwdS0+YXJjaC5jc3JyMDsN
Ci0Ja3ZtcHBjX3NldF9tc3IodmNwdSwgdmNwdS0+YXJjaC5jc3JyMSk7DQorCS8qIEZvcmNlIE1T
Ul9ERSB3aGVuIGd1ZXN0IGRvZXMgbm90IG93biBkZWJ1ZyBmYWNpbGl0aWVzICovDQorCWlmICh2
Y3B1LT5ndWVzdF9kZWJ1ZykNCisJCWt2bXBwY19zZXRfbXNyKHZjcHUsIHZjcHUtPmFyY2guY3Ny
cjEgfCBNU1JfREUpOw0KKwllbHNlDQorCQlrdm1wcGNfc2V0X21zcih2Y3B1LCB2Y3B1LT5hcmNo
LmNzcnIxKTsNCiB9DQogDQogc3RhdGljIHZvaWQga3ZtcHBjX2VtdWxfcmZtY2koc3RydWN0IGt2
bV92Y3B1ICp2Y3B1KQ0KQEAgLTc4LDYgKzkzLDEyIEBAIGludCBrdm1wcGNfYm9va2VfZW11bGF0
ZV9vcChzdHJ1Y3Qga3ZtX3J1biAqcnVuLCBzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUsDQogCQkJKmFk
dmFuY2UgPSAwOw0KIAkJCWJyZWFrOw0KIA0KKwkJY2FzZSBPUF8xOV9YT1BfUkZESToNCisJCQlr
dm1wcGNfZW11bF9yZmRpKHZjcHUpOw0KKy8vCQkJa3ZtcHBjX3NldF9leGl0X3R5cGUodmNwdSwg
RU1VTEFURURfUkZESV9FWElUUyk7DQorCQkJKmFkdmFuY2UgPSAwOw0KKwkJCWJyZWFrOw0KKw0K
IAkJZGVmYXVsdDoNCiAJCQllbXVsYXRlZCA9IEVNVUxBVEVfRkFJTDsNCiAJCQlicmVhazsNCkBA
IC0xMzEsNiArMTUyLDcgQEAgaW50IGt2bXBwY19ib29rZV9lbXVsYXRlX29wKHN0cnVjdCBrdm1f
cnVuICpydW4sIHN0cnVjdCBrdm1fdmNwdSAqdmNwdSwNCiBpbnQga3ZtcHBjX2Jvb2tlX2VtdWxh
dGVfbXRzcHIoc3RydWN0IGt2bV92Y3B1ICp2Y3B1LCBpbnQgc3BybiwgdWxvbmcgc3ByX3ZhbCkN
CiB7DQogCWludCBlbXVsYXRlZCA9IEVNVUxBVEVfRE9ORTsNCisJYm9vbCBkZWJ1Z19pbnN0ID0g
ZmFsc2U7DQogDQogCXN3aXRjaCAoc3Bybikgew0KIAljYXNlIFNQUk5fREVBUjoNCkBAIC0xNDUs
MjEgKzE2Nyw3NCBAQCBpbnQga3ZtcHBjX2Jvb2tlX2VtdWxhdGVfbXRzcHIoc3RydWN0IGt2bV92
Y3B1ICp2Y3B1LCBpbnQgc3BybiwgdWxvbmcgc3ByX3ZhbCkNCiAJY2FzZSBTUFJOX0NTUlIxOg0K
IAkJdmNwdS0+YXJjaC5jc3JyMSA9IHNwcl92YWw7DQogCQlicmVhazsNCi0JY2FzZSBTUFJOX0RC
Q1IwOg0KLQkJdmNwdS0+YXJjaC5kYmdfcmVnLmRiY3IwID0gc3ByX3ZhbDsNCisJY2FzZSBTUFJO
X0RTUlIwOg0KKwkJdmNwdS0+YXJjaC5kc3JyMCA9IHNwcl92YWw7DQogCQlicmVhazsNCi0JY2Fz
ZSBTUFJOX0RCQ1IxOg0KLQkJdmNwdS0+YXJjaC5kYmdfcmVnLmRiY3IxID0gc3ByX3ZhbDsNCisJ
Y2FzZSBTUFJOX0RTUlIxOg0KKwkJdmNwdS0+YXJjaC5kc3JyMSA9IHNwcl92YWw7DQorCQlicmVh
azsNCisJY2FzZSBTUFJOX0lBQzE6DQorCQlkZWJ1Z19pbnN0ID0gdHJ1ZTsNCisJCXZjcHUtPmFy
Y2guZGJnX3JlZy5pYWMxID0gc3ByX3ZhbDsNCisJCXZjcHUtPmFyY2guc2hhZG93X2RiZ19yZWcu
aWFjMSA9IHNwcl92YWw7DQorCQlicmVhazsNCisJY2FzZSBTUFJOX0lBQzI6DQorCQlkZWJ1Z19p
bnN0ID0gdHJ1ZTsNCisJCXZjcHUtPmFyY2guZGJnX3JlZy5pYWMyID0gc3ByX3ZhbDsNCisJCXZj
cHUtPmFyY2guc2hhZG93X2RiZ19yZWcuaWFjMiA9IHNwcl92YWw7DQorCQlicmVhazsNCisjaWZu
ZGVmIENPTkZJR19QUENfRlNMX0JPT0szRQ0KKwljYXNlIFNQUk5fSUFDMzoNCisJCWRlYnVnX2lu
c3QgPSB0cnVlOw0KKwkJdmNwdS0+YXJjaC5kYmdfcmVnLmlhYzMgPSBzcHJfdmFsOw0KKwkJdmNw
dS0+YXJjaC5zaGFkb3dfZGJnX3JlZy5pYWMzID0gc3ByX3ZhbDsNCiAJCWJyZWFrOw0KKwljYXNl
IFNQUk5fSUFDNDoNCisJCWRlYnVnX2luc3QgPSB0cnVlOw0KKwkJdmNwdS0+YXJjaC5kYmdfcmVn
LmlhYzQgPSBzcHJfdmFsOw0KKwkJdmNwdS0+YXJjaC5zaGFkb3dfZGJnX3JlZy5pYWM0ID0gc3By
X3ZhbDsNCisJCWJyZWFrOw0KKyNlbmRpZg0KKwljYXNlIFNQUk5fREFDMToNCisJCWRlYnVnX2lu
c3QgPSB0cnVlOw0KKwkJdmNwdS0+YXJjaC5kYmdfcmVnLmRhYzEgPSBzcHJfdmFsOw0KKwkJdmNw
dS0+YXJjaC5zaGFkb3dfZGJnX3JlZy5kYWMxID0gc3ByX3ZhbDsNCisJCWJyZWFrOw0KKwljYXNl
IFNQUk5fREFDMjoNCisJCWRlYnVnX2luc3QgPSB0cnVlOw0KKwkJdmNwdS0+YXJjaC5kYmdfcmVn
LmRhYzIgPSBzcHJfdmFsOw0KKwkJdmNwdS0+YXJjaC5zaGFkb3dfZGJnX3JlZy5kYWMyID0gc3By
X3ZhbDsNCisJCWJyZWFrOw0KKyAJY2FzZSBTUFJOX0RCQ1IwOg0KKwkJZGVidWdfaW5zdCA9IHRy
dWU7DQorCQlzcHJfdmFsICY9IChEQkNSMF9JRE0gfCBEQkNSMF9JQyB8IERCQ1IwX0JUIHwgREJD
UjBfVElFIHwNCisJCQlEQkNSMF9JQUMxIHwgREJDUjBfSUFDMiB8IERCQ1IwX0lBQzMgfCBEQkNS
MF9JQUM0ICB8DQorCQkJREJDUjBfREFDMVIgfCBEQkNSMF9EQUMxVyB8IERCQ1IwX0RBQzJSIHwg
REJDUjBfREFDMlcpOw0KKw0KKyAJCXZjcHUtPmFyY2guZGJnX3JlZy5kYmNyMCA9IHNwcl92YWw7
DQorCQl2Y3B1LT5hcmNoLnNoYWRvd19kYmdfcmVnLmRiY3IwID0gc3ByX3ZhbDsNCisgCQlicmVh
azsNCisgCWNhc2UgU1BSTl9EQkNSMToNCisJCWRlYnVnX2luc3QgPSB0cnVlOw0KKyAJCXZjcHUt
PmFyY2guZGJnX3JlZy5kYmNyMSA9IHNwcl92YWw7DQorCQl2Y3B1LT5hcmNoLnNoYWRvd19kYmdf
cmVnLmRiY3IxID0gc3ByX3ZhbDsNCisJCWJyZWFrOw0KKwljYXNlIFNQUk5fREJDUjI6DQorCQlk
ZWJ1Z19pbnN0ID0gdHJ1ZTsNCisJCXZjcHUtPmFyY2guZGJnX3JlZy5kYmNyMiA9IHNwcl92YWw7
DQorCQl2Y3B1LT5hcmNoLnNoYWRvd19kYmdfcmVnLmRiY3IyID0gc3ByX3ZhbDsNCisgCQlicmVh
azsNCisgCWNhc2UgU1BSTl9EQlNSOg0KKyAJCXZjcHUtPmFyY2guZGJzciAmPSB+c3ByX3ZhbDsN
CisJCWlmICh2Y3B1LT5hcmNoLmRic3IgPT0gMCkNCisJCQlrdm1wcGNfY29yZV9kZXF1ZXVlX2Rl
YnVnKHZjcHUpOw0KKyAJCWJyZWFrOw0KIAljYXNlIFNQUk5fTUNTUlIwOg0KIAkJdmNwdS0+YXJj
aC5tY3NycjAgPSBzcHJfdmFsOw0KIAkJYnJlYWs7DQogCWNhc2UgU1BSTl9NQ1NSUjE6DQogCQl2
Y3B1LT5hcmNoLm1jc3JyMSA9IHNwcl92YWw7DQogCQlicmVhazsNCi0JY2FzZSBTUFJOX0RCU1I6
DQotCQl2Y3B1LT5hcmNoLmRic3IgJj0gfnNwcl92YWw7DQotCQlicmVhazsNCiAJY2FzZSBTUFJO
X1RTUjoNCiAJCWt2bXBwY19jbHJfdHNyX2JpdHModmNwdSwgc3ByX3ZhbCk7DQogCQlicmVhazsN
CkBAIC0yNzEsNiArMzQ2LDEwIEBAIGludCBrdm1wcGNfYm9va2VfZW11bGF0ZV9tdHNwcihzdHJ1
Y3Qga3ZtX3ZjcHUgKnZjcHUsIGludCBzcHJuLCB1bG9uZyBzcHJfdmFsKQ0KIAkJZW11bGF0ZWQg
PSBFTVVMQVRFX0ZBSUw7DQogCX0NCiANCisJaWYgKGRlYnVnX2luc3QpIHsNCisJCXN3aXRjaF9i
b29rZV9kZWJ1Z19yZWdzKCZ2Y3B1LT5hcmNoLnNoYWRvd19kYmdfcmVnKTsNCisJCWN1cnJlbnQt
PnRocmVhZC5kZWJ1ZyA9IHZjcHUtPmFyY2guc2hhZG93X2RiZ19yZWc7DQorCX0NCiAJcmV0dXJu
IGVtdWxhdGVkOw0KIH0NCiANCkBAIC0yOTcsMTIgKzM3Niw0MSBAQCBpbnQga3ZtcHBjX2Jvb2tl
X2VtdWxhdGVfbWZzcHIoc3RydWN0IGt2bV92Y3B1ICp2Y3B1LCBpbnQgc3BybiwgdWxvbmcgKnNw
cl92YWwpDQogCWNhc2UgU1BSTl9DU1JSMToNCiAJCSpzcHJfdmFsID0gdmNwdS0+YXJjaC5jc3Jy
MTsNCiAJCWJyZWFrOw0KKwljYXNlIFNQUk5fRFNSUjA6DQorCQkqc3ByX3ZhbCA9IHZjcHUtPmFy
Y2guZHNycjA7DQorCQlicmVhazsNCisJY2FzZSBTUFJOX0RTUlIxOg0KKwkJKnNwcl92YWwgPSB2
Y3B1LT5hcmNoLmRzcnIxOw0KKwkJYnJlYWs7DQorCWNhc2UgU1BSTl9JQUMxOg0KKwkJKnNwcl92
YWwgPSB2Y3B1LT5hcmNoLmRiZ19yZWcuaWFjMTsNCisJCWJyZWFrOw0KKwljYXNlIFNQUk5fSUFD
MjoNCisJCSpzcHJfdmFsID0gdmNwdS0+YXJjaC5kYmdfcmVnLmlhYzI7DQorCQlicmVhazsNCisj
aWZuZGVmIENPTkZJR19QUENfRlNMX0JPT0szRQ0KKwljYXNlIFNQUk5fSUFDMzoNCisJCSpzcHJf
dmFsID0gdmNwdS0+YXJjaC5kYmdfcmVnLmlhYzM7DQorCQlicmVhazsNCisJY2FzZSBTUFJOX0lB
QzQ6DQorCQkqc3ByX3ZhbCA9IHZjcHUtPmFyY2guZGJnX3JlZy5pYWM0Ow0KKwkJYnJlYWs7DQor
I2VuZGlmDQorCWNhc2UgU1BSTl9EQUMxOg0KKwkJKnNwcl92YWwgPSB2Y3B1LT5hcmNoLmRiZ19y
ZWcuZGFjMTsNCisJCWJyZWFrOw0KKwljYXNlIFNQUk5fREFDMjoNCisJCSpzcHJfdmFsID0gdmNw
dS0+YXJjaC5kYmdfcmVnLmRhYzI7DQorCQlicmVhazsNCiAJY2FzZSBTUFJOX0RCQ1IwOg0KIAkJ
KnNwcl92YWwgPSB2Y3B1LT5hcmNoLmRiZ19yZWcuZGJjcjA7DQogCQlicmVhazsNCiAJY2FzZSBT
UFJOX0RCQ1IxOg0KIAkJKnNwcl92YWwgPSB2Y3B1LT5hcmNoLmRiZ19yZWcuZGJjcjE7DQogCQli
cmVhazsNCisJY2FzZSBTUFJOX0RCQ1IyOg0KKwkJKnNwcl92YWwgPSB2Y3B1LT5hcmNoLmRiZ19y
ZWcuZGJjcjI7DQorCQlicmVhazsNCiAJY2FzZSBTUFJOX01DU1JSMDoNCiAJCSpzcHJfdmFsID0g
dmNwdS0+YXJjaC5tY3NycjA7DQogCQlicmVhazsNCmRpZmYgLS1naXQgYS9hcmNoL3Bvd2VycGMv
a3ZtL2U1MDBtYy5jIGIvYXJjaC9wb3dlcnBjL2t2bS9lNTAwbWMuYw0KaW5kZXggYmJmN2NkZC4u
NTYwYjU3NiAxMDA2NDQNCi0tLSBhL2FyY2gvcG93ZXJwYy9rdm0vZTUwMG1jLmMNCisrKyBiL2Fy
Y2gvcG93ZXJwYy9rdm0vZTUwMG1jLmMNCkBAIC0yNDksNyArMjQ5LDcgQEAgaW50IGt2bXBwY19j
b3JlX3ZjcHVfc2V0dXAoc3RydWN0IGt2bV92Y3B1ICp2Y3B1KQ0KICNpZmRlZiBDT05GSUdfNjRC
SVQNCiAJdmNwdS0+YXJjaC5zaGFkb3dfZXBjciB8PSBTUFJOX0VQQ1JfSUNNOw0KICNlbmRpZg0K
LQl2Y3B1LT5hcmNoLnNoYWRvd19tc3JwID0gTVNSUF9VQ0xFUCB8IE1TUlBfREVQIHwgTVNSUF9Q
TU1QOw0KKwl2Y3B1LT5hcmNoLnNoYWRvd19tc3JwID0gTVNSUF9VQ0xFUCB8IE1TUlBfUE1NUDsN
CiANCiAJdmNwdS0+YXJjaC5wdnIgPSBtZnNwcihTUFJOX1BWUik7DQogCXZjcHVfZTUwMC0+c3Zy
ID0gbWZzcHIoU1BSTl9TVlIpOw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGFua3MNCi1C
aGFyYXQNCg0KPiANCj4gLVNjb3R0DQo+IA0KDQo

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

> -----Original Message-----
> From: Bhushan Bharat-R65777
> Sent: Wednesday, July 02, 2014 5:07 PM
> To: Wood Scott-B07421; Alexander Graf
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
> guest
> 
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, July 01, 2014 10:11 PM
> > To: Alexander Graf
> > Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org;
> > kvm@vger.kernel.org
> > Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
> > injection to guest
> >
> > On Tue, 2014-07-01 at 18:22 +0200, Alexander Graf wrote:
> > > On 01.07.14 17:35, Scott Wood wrote:
> > > > On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
> > > >> On 01.07.14 16:58, Scott Wood wrote:
> > > >>> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
> > > >>>> I don't think QEMU should be aware of these limitations.
> > > >>> OK, but we should at least have some idea of how the whole thing
> > > >>> is supposed to work, in order to determine if this is the
> > > >>> correct behavior for QEMU.  I thought the model was that debug
> > > >>> resources are either owned by QEMU or by the guest, and in the
> > > >>> latter case, QEMU would never see the debug exception to begin with.
> > > >> That's bad for a number of reasons. For starters it's different
> > > >> from how
> > > >> x86 handles debug registers - and I hate to be different just for
> > > >> the sake of being different.
> > > > How does it work on x86?
> > >
> > > It overwrites more-or-less random breakpoints with its own ones, but
> > > leaves the others intact ;).
> >
> > Are you talking about software breakpoints or management of hardware
> > debug registers?
> >
> > > >> So if we do want to declare that debug registers are owned by
> > > >> either QEMU or the guest, we should change the semantics for all
> > > >> architectures.
> > > > If we want to say that ownership of the registers is shared, we
> > > > need a plan for how that would actually work.
> > >
> > > I think you're overengineering here :). When do people actually use
> > > gdbstub? Usually when they want to debug a broken guest. We can
> > > either
> > >
> > >    * overengineer heavily and reduce the number of registers
> > > available to the guest to always have spares
> > >    * overengineer a bit and turn off guest debugging completely when
> > > we use gdbstub
> > >    * just leave as much alive as we can, hoping that it helps with
> > > the debugging
> > >
> > > Option 3 is what x86 does - and I think it's a reasonable approach.
> > > This is not an interface that needs to be 100% consistent and bullet
> > > proof, it's a best effort to enable you to debug as much as possible.
> >
> > I'm not insisting on 100% -- just hoping for some
> > explanation/discussion about how it's intended to work for the cases where it
> can.
> >
> > How will MSR[DE] and MSRP[DEP] be handled?
> >
> > How would I go about telling QEMU/KVM that I don't want this shared
> > mode, because I don't want guest to interfere with the debugging I'm
> > trying to do from QEMU?
> >
> > Will guest accesses to debug registers cause a userspace exit when
> > guest_debug is enabled?
> >
> > > >> I think we're in a path that is slow enough already to not worry
> > > >> about performance.
> > > > It's not just about performance, but simplicity of use, and
> > > > consistency of API.
> > > >
> > > > Oh, and it looks like there already exist one reg definitions and
> > > > implementations for most of the debug registers.
> > >
> > > For BookE? Where?
> >
> > arch/powerpc/kvm/booke.c: KVM_REG_PPC_IACn, KVM_REG_PPC_DACn
> 
> I tried to quickly prototype what I think we want to do (this is not tested)

Hi Scott,

There is one problem which is stopping us to share debug resource between qemu and guest, looking for suggestions:
- As qemu is also using debug resource,  We have to set MSR_DE and set MSRP_DEP (guest will not be able to clear MSR_DE). So qemu set debug events will always cause the debug interrupts.
- Now guest is also using debug resources and for some reason if guest wants to clear MSR_DE (disable debug interrupt) But it will not be able to disable as MSRP_DEP is set and KVM will not come to know guest willingness to disable MSR_DE.
- If the debug interrupts occurs then we will exit to QEMU and this may not a QEMU set event so it will inject interrupt to guest (using one-reg or set-sregs)
- Now KVM, when handling one-reg/sregs request to inject debug interrupt, do not know whether guest can handle the debug interrupt or not (as guest might have tried to set/clear MSR_DE).

Thanks
-Bharat

> 
> -----------------------------------------------------------------------
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h
> b/arch/powerpc/include/asm/kvm_ppc.h
> index e8b3982..746b5c6 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -179,6 +179,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);
> +
>  /*
>   * Cuts out inst bits with ordering according to spec.
>   * That means the leftmost bit is zero. All given bits are included.
> diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c index
> 9f13056..0b7e4e4 100644
> --- a/arch/powerpc/kvm/booke.c
> +++ b/arch/powerpc/kvm/booke.c
> @@ -235,6 +235,16 @@ void kvmppc_core_dequeue_dec(struct kvm_vcpu *vcpu)
>  	clear_bit(BOOKE_IRQPRIO_DECREMENTER, &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); }
> +
>  void kvmppc_core_queue_external(struct kvm_vcpu *vcpu,
>                                  struct kvm_interrupt *irq)  { @@ -841,6 +851,20
> @@ 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;
> 
> +	/* Userspace (QEMU) is not using debug resource, so inject debug interrupt
> +	 * directly to guest debug.
> +	 */
> +	if (vcpu->guest_debug == 0) {
> +		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;
> +	}
> +
>  	run->debug.arch.status = 0;
>  	run->debug.arch.address = vcpu->arch.pc;
> 
> @@ -1920,7 +1944,7 @@ int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu
> *vcpu,
>  	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;
> +//	vcpu->arch.dbg_reg.dbcr0 = DBCR0_EDM;
> 
>  	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
>  		vcpu->arch.shadow_dbg_reg.dbcr0 |= DBCR0_IDM | DBCR0_IC; diff --git
> a/arch/powerpc/kvm/booke_emulate.c b/arch/powerpc/kvm/booke_emulate.c
> index aaff1b7..ef8de7f 100644
> --- a/arch/powerpc/kvm/booke_emulate.c
> +++ b/arch/powerpc/kvm/booke_emulate.c
> @@ -26,6 +26,7 @@
>  #define OP_19_XOP_RFMCI   38
>  #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
> @@ -38,10 +39,24 @@ 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;
> -	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);
>  }
> 
>  static void kvmppc_emul_rfmci(struct kvm_vcpu *vcpu) @@ -78,6 +93,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;
> @@ -131,6 +152,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:
> @@ -145,21 +167,74 @@ 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_DBCR0:
> -		vcpu->arch.dbg_reg.dbcr0 = spr_val;
> +	case SPRN_DSRR0:
> +		vcpu->arch.dsrr0 = spr_val;
>  		break;
> -	case SPRN_DBCR1:
> -		vcpu->arch.dbg_reg.dbcr1 = spr_val;
> +	case SPRN_DSRR1:
> +		vcpu->arch.dsrr1 = spr_val;
> +		break;
> +	case SPRN_IAC1:
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac1 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac1 = spr_val;
> +		break;
> +	case SPRN_IAC2:
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac2 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac2 = spr_val;
> +		break;
> +#ifndef CONFIG_PPC_FSL_BOOK3E
> +	case SPRN_IAC3:
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac3 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac3 = spr_val;
>  		break;
> +	case SPRN_IAC4:
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.iac4 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.iac4 = spr_val;
> +		break;
> +#endif
> +	case SPRN_DAC1:
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.dac1 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dac1 = spr_val;
> +		break;
> +	case SPRN_DAC2:
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.dac2 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dac2 = spr_val;
> +		break;
> + 	case SPRN_DBCR0:
> +		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:
> +		debug_inst = true;
> + 		vcpu->arch.dbg_reg.dbcr1 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dbcr1 = spr_val;
> +		break;
> +	case SPRN_DBCR2:
> +		debug_inst = true;
> +		vcpu->arch.dbg_reg.dbcr2 = spr_val;
> +		vcpu->arch.shadow_dbg_reg.dbcr2 = spr_val;
> + 		break;
> + 	case SPRN_DBSR:
> + 		vcpu->arch.dbsr &= ~spr_val;
> +		if (vcpu->arch.dbsr == 0)
> +			kvmppc_core_dequeue_debug(vcpu);
> + 		break;
>  	case SPRN_MCSRR0:
>  		vcpu->arch.mcsrr0 = spr_val;
>  		break;
>  	case SPRN_MCSRR1:
>  		vcpu->arch.mcsrr1 = spr_val;
>  		break;
> -	case SPRN_DBSR:
> -		vcpu->arch.dbsr &= ~spr_val;
> -		break;
>  	case SPRN_TSR:
>  		kvmppc_clr_tsr_bits(vcpu, spr_val);
>  		break;
> @@ -271,6 +346,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;
>  }
> 
> @@ -297,12 +376,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;
> +#ifndef CONFIG_PPC_FSL_BOOK3E
> +	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_MCSRR0:
>  		*spr_val = vcpu->arch.mcsrr0;
>  		break;
> diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c index
> bbf7cdd..560b576 100644
> --- a/arch/powerpc/kvm/e500mc.c
> +++ b/arch/powerpc/kvm/e500mc.c
> @@ -249,7 +249,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.pvr = mfspr(SPRN_PVR);
>  	vcpu_e500->svr = mfspr(SPRN_SVR);
> 
> 
> ------------------
> 
> Thanks
> -Bharat
> 
> >
> > -Scott
> >

RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Bharat.Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmh1c2hhbiBCaGFyYXQt
UjY1Nzc3DQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAwMiwgMjAxNCA1OjA3IFBNDQo+IFRvOiBX
b29kIFNjb3R0LUIwNzQyMTsgQWxleGFuZGVyIEdyYWYNCj4gQ2M6IGt2bS1wcGNAdmdlci5rZXJu
ZWwub3JnOyBrdm1Admdlci5rZXJuZWwub3JnDQo+IFN1YmplY3Q6IFJFOiBbUEFUQ0ggMi8yXSBL
Vk0gOiBwb3dlcnBjL2Jvb2tlOiBBbGxvdyBkZWJ1ZyBpbnRlcnJ1cHQgaW5qZWN0aW9uIHRvDQo+
IGd1ZXN0DQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206
IFdvb2QgU2NvdHQtQjA3NDIxDQo+ID4gU2VudDogVHVlc2RheSwgSnVseSAwMSwgMjAxNCAxMDox
MSBQTQ0KPiA+IFRvOiBBbGV4YW5kZXIgR3JhZg0KPiA+IENjOiBCaHVzaGFuIEJoYXJhdC1SNjU3
Nzc7IGt2bS1wcGNAdmdlci5rZXJuZWwub3JnOw0KPiA+IGt2bUB2Z2VyLmtlcm5lbC5vcmcNCj4g
PiBTdWJqZWN0OiBSZTogW1BBVENIIDIvMl0gS1ZNIDogcG93ZXJwYy9ib29rZTogQWxsb3cgZGVi
dWcgaW50ZXJydXB0DQo+ID4gaW5qZWN0aW9uIHRvIGd1ZXN0DQo+ID4NCj4gPiBPbiBUdWUsIDIw
MTQtMDctMDEgYXQgMTg6MjIgKzAyMDAsIEFsZXhhbmRlciBHcmFmIHdyb3RlOg0KPiA+ID4gT24g
MDEuMDcuMTQgMTc6MzUsIFNjb3R0IFdvb2Qgd3JvdGU6DQo+ID4gPiA+IE9uIFR1ZSwgMjAxNC0w
Ny0wMSBhdCAxNzowNCArMDIwMCwgQWxleGFuZGVyIEdyYWYgd3JvdGU6DQo+ID4gPiA+PiBPbiAw
MS4wNy4xNCAxNjo1OCwgU2NvdHQgV29vZCB3cm90ZToNCj4gPiA+ID4+PiBPbiBUdWUsIDIwMTQt
MDctMDEgYXQgMDg6MjMgKzAyMDAsIEFsZXhhbmRlciBHcmFmIHdyb3RlOg0KPiA+ID4gPj4+PiBJ
IGRvbid0IHRoaW5rIFFFTVUgc2hvdWxkIGJlIGF3YXJlIG9mIHRoZXNlIGxpbWl0YXRpb25zLg0K
PiA+ID4gPj4+IE9LLCBidXQgd2Ugc2hvdWxkIGF0IGxlYXN0IGhhdmUgc29tZSBpZGVhIG9mIGhv
dyB0aGUgd2hvbGUgdGhpbmcNCj4gPiA+ID4+PiBpcyBzdXBwb3NlZCB0byB3b3JrLCBpbiBvcmRl
ciB0byBkZXRlcm1pbmUgaWYgdGhpcyBpcyB0aGUNCj4gPiA+ID4+PiBjb3JyZWN0IGJlaGF2aW9y
IGZvciBRRU1VLiAgSSB0aG91Z2h0IHRoZSBtb2RlbCB3YXMgdGhhdCBkZWJ1Zw0KPiA+ID4gPj4+
IHJlc291cmNlcyBhcmUgZWl0aGVyIG93bmVkIGJ5IFFFTVUgb3IgYnkgdGhlIGd1ZXN0LCBhbmQg
aW4gdGhlDQo+ID4gPiA+Pj4gbGF0dGVyIGNhc2UsIFFFTVUgd291bGQgbmV2ZXIgc2VlIHRoZSBk
ZWJ1ZyBleGNlcHRpb24gdG8gYmVnaW4gd2l0aC4NCj4gPiA+ID4+IFRoYXQncyBiYWQgZm9yIGEg
bnVtYmVyIG9mIHJlYXNvbnMuIEZvciBzdGFydGVycyBpdCdzIGRpZmZlcmVudA0KPiA+ID4gPj4g
ZnJvbSBob3cNCj4gPiA+ID4+IHg4NiBoYW5kbGVzIGRlYnVnIHJlZ2lzdGVycyAtIGFuZCBJIGhh
dGUgdG8gYmUgZGlmZmVyZW50IGp1c3QgZm9yDQo+ID4gPiA+PiB0aGUgc2FrZSBvZiBiZWluZyBk
aWZmZXJlbnQuDQo+ID4gPiA+IEhvdyBkb2VzIGl0IHdvcmsgb24geDg2Pw0KPiA+ID4NCj4gPiA+
IEl0IG92ZXJ3cml0ZXMgbW9yZS1vci1sZXNzIHJhbmRvbSBicmVha3BvaW50cyB3aXRoIGl0cyBv
d24gb25lcywgYnV0DQo+ID4gPiBsZWF2ZXMgdGhlIG90aGVycyBpbnRhY3QgOykuDQo+ID4NCj4g
PiBBcmUgeW91IHRhbGtpbmcgYWJvdXQgc29mdHdhcmUgYnJlYWtwb2ludHMgb3IgbWFuYWdlbWVu
dCBvZiBoYXJkd2FyZQ0KPiA+IGRlYnVnIHJlZ2lzdGVycz8NCj4gPg0KPiA+ID4gPj4gU28gaWYg
d2UgZG8gd2FudCB0byBkZWNsYXJlIHRoYXQgZGVidWcgcmVnaXN0ZXJzIGFyZSBvd25lZCBieQ0K
PiA+ID4gPj4gZWl0aGVyIFFFTVUgb3IgdGhlIGd1ZXN0LCB3ZSBzaG91bGQgY2hhbmdlIHRoZSBz
ZW1hbnRpY3MgZm9yIGFsbA0KPiA+ID4gPj4gYXJjaGl0ZWN0dXJlcy4NCj4gPiA+ID4gSWYgd2Ug
d2FudCB0byBzYXkgdGhhdCBvd25lcnNoaXAgb2YgdGhlIHJlZ2lzdGVycyBpcyBzaGFyZWQsIHdl
DQo+ID4gPiA+IG5lZWQgYSBwbGFuIGZvciBob3cgdGhhdCB3b3VsZCBhY3R1YWxseSB3b3JrLg0K
PiA+ID4NCj4gPiA+IEkgdGhpbmsgeW91J3JlIG92ZXJlbmdpbmVlcmluZyBoZXJlIDopLiBXaGVu
IGRvIHBlb3BsZSBhY3R1YWxseSB1c2UNCj4gPiA+IGdkYnN0dWI/IFVzdWFsbHkgd2hlbiB0aGV5
IHdhbnQgdG8gZGVidWcgYSBicm9rZW4gZ3Vlc3QuIFdlIGNhbg0KPiA+ID4gZWl0aGVyDQo+ID4g
Pg0KPiA+ID4gICAgKiBvdmVyZW5naW5lZXIgaGVhdmlseSBhbmQgcmVkdWNlIHRoZSBudW1iZXIg
b2YgcmVnaXN0ZXJzDQo+ID4gPiBhdmFpbGFibGUgdG8gdGhlIGd1ZXN0IHRvIGFsd2F5cyBoYXZl
IHNwYXJlcw0KPiA+ID4gICAgKiBvdmVyZW5naW5lZXIgYSBiaXQgYW5kIHR1cm4gb2ZmIGd1ZXN0
IGRlYnVnZ2luZyBjb21wbGV0ZWx5IHdoZW4NCj4gPiA+IHdlIHVzZSBnZGJzdHViDQo+ID4gPiAg
ICAqIGp1c3QgbGVhdmUgYXMgbXVjaCBhbGl2ZSBhcyB3ZSBjYW4sIGhvcGluZyB0aGF0IGl0IGhl
bHBzIHdpdGgNCj4gPiA+IHRoZSBkZWJ1Z2dpbmcNCj4gPiA+DQo+ID4gPiBPcHRpb24gMyBpcyB3
aGF0IHg4NiBkb2VzIC0gYW5kIEkgdGhpbmsgaXQncyBhIHJlYXNvbmFibGUgYXBwcm9hY2guDQo+
ID4gPiBUaGlzIGlzIG5vdCBhbiBpbnRlcmZhY2UgdGhhdCBuZWVkcyB0byBiZSAxMDAlIGNvbnNp
c3RlbnQgYW5kIGJ1bGxldA0KPiA+ID4gcHJvb2YsIGl0J3MgYSBiZXN0IGVmZm9ydCB0byBlbmFi
bGUgeW91IHRvIGRlYnVnIGFzIG11Y2ggYXMgcG9zc2libGUuDQo+ID4NCj4gPiBJJ20gbm90IGlu
c2lzdGluZyBvbiAxMDAlIC0tIGp1c3QgaG9waW5nIGZvciBzb21lDQo+ID4gZXhwbGFuYXRpb24v
ZGlzY3Vzc2lvbiBhYm91dCBob3cgaXQncyBpbnRlbmRlZCB0byB3b3JrIGZvciB0aGUgY2FzZXMg
d2hlcmUgaXQNCj4gY2FuLg0KPiA+DQo+ID4gSG93IHdpbGwgTVNSW0RFXSBhbmQgTVNSUFtERVBd
IGJlIGhhbmRsZWQ/DQo+ID4NCj4gPiBIb3cgd291bGQgSSBnbyBhYm91dCB0ZWxsaW5nIFFFTVUv
S1ZNIHRoYXQgSSBkb24ndCB3YW50IHRoaXMgc2hhcmVkDQo+ID4gbW9kZSwgYmVjYXVzZSBJIGRv
bid0IHdhbnQgZ3Vlc3QgdG8gaW50ZXJmZXJlIHdpdGggdGhlIGRlYnVnZ2luZyBJJ20NCj4gPiB0
cnlpbmcgdG8gZG8gZnJvbSBRRU1VPw0KPiA+DQo+ID4gV2lsbCBndWVzdCBhY2Nlc3NlcyB0byBk
ZWJ1ZyByZWdpc3RlcnMgY2F1c2UgYSB1c2Vyc3BhY2UgZXhpdCB3aGVuDQo+ID4gZ3Vlc3RfZGVi
dWcgaXMgZW5hYmxlZD8NCj4gPg0KPiA+ID4gPj4gSSB0aGluayB3ZSdyZSBpbiBhIHBhdGggdGhh
dCBpcyBzbG93IGVub3VnaCBhbHJlYWR5IHRvIG5vdCB3b3JyeQ0KPiA+ID4gPj4gYWJvdXQgcGVy
Zm9ybWFuY2UuDQo+ID4gPiA+IEl0J3Mgbm90IGp1c3QgYWJvdXQgcGVyZm9ybWFuY2UsIGJ1dCBz
aW1wbGljaXR5IG9mIHVzZSwgYW5kDQo+ID4gPiA+IGNvbnNpc3RlbmN5IG9mIEFQSS4NCj4gPiA+
ID4NCj4gPiA+ID4gT2gsIGFuZCBpdCBsb29rcyBsaWtlIHRoZXJlIGFscmVhZHkgZXhpc3Qgb25l
IHJlZyBkZWZpbml0aW9ucyBhbmQNCj4gPiA+ID4gaW1wbGVtZW50YXRpb25zIGZvciBtb3N0IG9m
IHRoZSBkZWJ1ZyByZWdpc3RlcnMuDQo+ID4gPg0KPiA+ID4gRm9yIEJvb2tFPyBXaGVyZT8NCj4g
Pg0KPiA+IGFyY2gvcG93ZXJwYy9rdm0vYm9va2UuYzogS1ZNX1JFR19QUENfSUFDbiwgS1ZNX1JF
R19QUENfREFDbg0KPiANCj4gSSB0cmllZCB0byBxdWlja2x5IHByb3RvdHlwZSB3aGF0IEkgdGhp
bmsgd2Ugd2FudCB0byBkbyAodGhpcyBpcyBub3QgdGVzdGVkKQ0KDQpIaSBTY290dCwNCg0KVGhl
cmUgaXMgb25lIHByb2JsZW0gd2hpY2ggaXMgc3RvcHBpbmcgdXMgdG8gc2hhcmUgZGVidWcgcmVz
b3VyY2UgYmV0d2VlbiBxZW11IGFuZCBndWVzdCwgbG9va2luZyBmb3Igc3VnZ2VzdGlvbnM6DQot
IEFzIHFlbXUgaXMgYWxzbyB1c2luZyBkZWJ1ZyByZXNvdXJjZSwgIFdlIGhhdmUgdG8gc2V0IE1T
Ul9ERSBhbmQgc2V0IE1TUlBfREVQIChndWVzdCB3aWxsIG5vdCBiZSBhYmxlIHRvIGNsZWFyIE1T
Ul9ERSkuIFNvIHFlbXUgc2V0IGRlYnVnIGV2ZW50cyB3aWxsIGFsd2F5cyBjYXVzZSB0aGUgZGVi
dWcgaW50ZXJydXB0cy4NCi0gTm93IGd1ZXN0IGlzIGFsc28gdXNpbmcgZGVidWcgcmVzb3VyY2Vz
IGFuZCBmb3Igc29tZSByZWFzb24gaWYgZ3Vlc3Qgd2FudHMgdG8gY2xlYXIgTVNSX0RFIChkaXNh
YmxlIGRlYnVnIGludGVycnVwdCkgQnV0IGl0IHdpbGwgbm90IGJlIGFibGUgdG8gZGlzYWJsZSBh
cyBNU1JQX0RFUCBpcyBzZXQgYW5kIEtWTSB3aWxsIG5vdCBjb21lIHRvIGtub3cgZ3Vlc3Qgd2ls
bGluZ25lc3MgdG8gZGlzYWJsZSBNU1JfREUuDQotIElmIHRoZSBkZWJ1ZyBpbnRlcnJ1cHRzIG9j
Y3VycyB0aGVuIHdlIHdpbGwgZXhpdCB0byBRRU1VIGFuZCB0aGlzIG1heSBub3QgYSBRRU1VIHNl
dCBldmVudCBzbyBpdCB3aWxsIGluamVjdCBpbnRlcnJ1cHQgdG8gZ3Vlc3QgKHVzaW5nIG9uZS1y
ZWcgb3Igc2V0LXNyZWdzKQ0KLSBOb3cgS1ZNLCB3aGVuIGhhbmRsaW5nIG9uZS1yZWcvc3JlZ3Mg
cmVxdWVzdCB0byBpbmplY3QgZGVidWcgaW50ZXJydXB0LCBkbyBub3Qga25vdyB3aGV0aGVyIGd1
ZXN0IGNhbiBoYW5kbGUgdGhlIGRlYnVnIGludGVycnVwdCBvciBub3QgKGFzIGd1ZXN0IG1pZ2h0
IGhhdmUgdHJpZWQgdG8gc2V0L2NsZWFyIE1TUl9ERSkuDQoNClRoYW5rcw0KLUJoYXJhdA0KDQo+
IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL2luY2x1ZGUv
YXNtL2t2bV9wcGMuaA0KPiBiL2FyY2gvcG93ZXJwYy9pbmNsdWRlL2FzbS9rdm1fcHBjLmgNCj4g
aW5kZXggZThiMzk4Mi4uNzQ2YjVjNiAxMDA2NDQNCj4gLS0tIGEvYXJjaC9wb3dlcnBjL2luY2x1
ZGUvYXNtL2t2bV9wcGMuaA0KPiArKysgYi9hcmNoL3Bvd2VycGMvaW5jbHVkZS9hc20va3ZtX3Bw
Yy5oDQo+IEBAIC0xNzksNiArMTc5LDkgQEAgZXh0ZXJuIGludCBrdm1wcGNfeGljc19nZXRfeGl2
ZShzdHJ1Y3Qga3ZtICprdm0sIHUzMiBpcnEsDQo+IHUzMiAqc2VydmVyLCAgZXh0ZXJuIGludCBr
dm1wcGNfeGljc19pbnRfb24oc3RydWN0IGt2bSAqa3ZtLCB1MzIgaXJxKTsgIGV4dGVybg0KPiBp
bnQga3ZtcHBjX3hpY3NfaW50X29mZihzdHJ1Y3Qga3ZtICprdm0sIHUzMiBpcnEpOw0KPiANCj4g
K3ZvaWQga3ZtcHBjX2NvcmVfZGVxdWV1ZV9kZWJ1ZyhzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUpOyB2
b2lkDQo+ICtrdm1wcGNfY29yZV9xdWV1ZV9kZWJ1ZyhzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUpOw0K
PiArDQo+ICAvKg0KPiAgICogQ3V0cyBvdXQgaW5zdCBiaXRzIHdpdGggb3JkZXJpbmcgYWNjb3Jk
aW5nIHRvIHNwZWMuDQo+ICAgKiBUaGF0IG1lYW5zIHRoZSBsZWZ0bW9zdCBiaXQgaXMgemVyby4g
QWxsIGdpdmVuIGJpdHMgYXJlIGluY2x1ZGVkLg0KPiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBj
L2t2bS9ib29rZS5jIGIvYXJjaC9wb3dlcnBjL2t2bS9ib29rZS5jIGluZGV4DQo+IDlmMTMwNTYu
LjBiN2U0ZTQgMTAwNjQ0DQo+IC0tLSBhL2FyY2gvcG93ZXJwYy9rdm0vYm9va2UuYw0KPiArKysg
Yi9hcmNoL3Bvd2VycGMva3ZtL2Jvb2tlLmMNCj4gQEAgLTIzNSw2ICsyMzUsMTYgQEAgdm9pZCBr
dm1wcGNfY29yZV9kZXF1ZXVlX2RlYyhzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUpDQo+ICAJY2xlYXJf
Yml0KEJPT0tFX0lSUVBSSU9fREVDUkVNRU5URVIsICZ2Y3B1LT5hcmNoLnBlbmRpbmdfZXhjZXB0
aW9ucyk7ICB9DQo+IA0KPiArdm9pZCBrdm1wcGNfY29yZV9xdWV1ZV9kZWJ1ZyhzdHJ1Y3Qga3Zt
X3ZjcHUgKnZjcHUpIHsNCj4gKwlrdm1wcGNfYm9va2VfcXVldWVfaXJxcHJpbyh2Y3B1LCBCT09L
RV9JUlFQUklPX0RFQlVHKTsgfQ0KPiArDQo+ICt2b2lkIGt2bXBwY19jb3JlX2RlcXVldWVfZGVi
dWcoc3RydWN0IGt2bV92Y3B1ICp2Y3B1KSB7DQo+ICsJY2xlYXJfYml0KEJPT0tFX0lSUVBSSU9f
REVCVUcsICZ2Y3B1LT5hcmNoLnBlbmRpbmdfZXhjZXB0aW9ucyk7IH0NCj4gKw0KPiAgdm9pZCBr
dm1wcGNfY29yZV9xdWV1ZV9leHRlcm5hbChzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUsDQo+ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0cnVjdCBrdm1faW50ZXJydXB0ICppcnEpICB7
IEBAIC04NDEsNiArODUxLDIwDQo+IEBAIHN0YXRpYyBpbnQga3ZtcHBjX2hhbmRsZV9kZWJ1Zyhz
dHJ1Y3Qga3ZtX3J1biAqcnVuLCBzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUpDQo+ICAJc3RydWN0IGRl
YnVnX3JlZyAqZGJnX3JlZyA9ICYodmNwdS0+YXJjaC5zaGFkb3dfZGJnX3JlZyk7DQo+ICAJdTMy
IGRic3IgPSB2Y3B1LT5hcmNoLmRic3I7DQo+IA0KPiArCS8qIFVzZXJzcGFjZSAoUUVNVSkgaXMg
bm90IHVzaW5nIGRlYnVnIHJlc291cmNlLCBzbyBpbmplY3QgZGVidWcgaW50ZXJydXB0DQo+ICsJ
ICogZGlyZWN0bHkgdG8gZ3Vlc3QgZGVidWcuDQo+ICsJICovDQo+ICsJaWYgKHZjcHUtPmd1ZXN0
X2RlYnVnID09IDApIHsNCj4gKwkJaWYgKGRic3IgJiYgKHZjcHUtPmFyY2guc2hhcmVkLT5tc3Ig
JiBNU1JfREUpKQ0KPiArCQkJa3ZtcHBjX2NvcmVfcXVldWVfZGVidWcodmNwdSk7DQo+ICsNCj4g
KwkJLyogSW5qZWN0IGEgcHJvZ3JhbSBpbnRlcnJ1cHQgaWYgdHJhcCBkZWJ1ZyBpcyBub3QgYWxs
b3dlZCAqLw0KPiArCQlpZiAoKGRic3IgJiBEQlNSX1RJRSkgJiYgISh2Y3B1LT5hcmNoLnNoYXJl
ZC0+bXNyICYgTVNSX0RFKSkNCj4gKwkJCWt2bXBwY19jb3JlX3F1ZXVlX3Byb2dyYW0odmNwdSwg
RVNSX1BUUik7DQo+ICsNCj4gKwkJcmV0dXJuIFJFU1VNRV9HVUVTVDsNCj4gKwl9DQo+ICsNCj4g
IAlydW4tPmRlYnVnLmFyY2guc3RhdHVzID0gMDsNCj4gIAlydW4tPmRlYnVnLmFyY2guYWRkcmVz
cyA9IHZjcHUtPmFyY2gucGM7DQo+IA0KPiBAQCAtMTkyMCw3ICsxOTQ0LDcgQEAgaW50IGt2bV9h
cmNoX3ZjcHVfaW9jdGxfc2V0X2d1ZXN0X2RlYnVnKHN0cnVjdCBrdm1fdmNwdQ0KPiAqdmNwdSwN
Cj4gIAl2Y3B1LT5ndWVzdF9kZWJ1ZyA9IGRiZy0+Y29udHJvbDsNCj4gIAl2Y3B1LT5hcmNoLnNo
YWRvd19kYmdfcmVnLmRiY3IwID0gMDsNCj4gIAkvKiBTZXQgREJDUjBfRURNIGluIGd1ZXN0IHZp
c2libGUgREJDUjAgcmVnaXN0ZXIuICovDQo+IC0JdmNwdS0+YXJjaC5kYmdfcmVnLmRiY3IwID0g
REJDUjBfRURNOw0KPiArLy8JdmNwdS0+YXJjaC5kYmdfcmVnLmRiY3IwID0gREJDUjBfRURNOw0K
PiANCj4gIAlpZiAodmNwdS0+Z3Vlc3RfZGVidWcgJiBLVk1fR1VFU1REQkdfU0lOR0xFU1RFUCkN
Cj4gIAkJdmNwdS0+YXJjaC5zaGFkb3dfZGJnX3JlZy5kYmNyMCB8PSBEQkNSMF9JRE0gfCBEQkNS
MF9JQzsgZGlmZiAtLWdpdA0KPiBhL2FyY2gvcG93ZXJwYy9rdm0vYm9va2VfZW11bGF0ZS5jIGIv
YXJjaC9wb3dlcnBjL2t2bS9ib29rZV9lbXVsYXRlLmMNCj4gaW5kZXggYWFmZjFiNy4uZWY4ZGU3
ZiAxMDA2NDQNCj4gLS0tIGEvYXJjaC9wb3dlcnBjL2t2bS9ib29rZV9lbXVsYXRlLmMNCj4gKysr
IGIvYXJjaC9wb3dlcnBjL2t2bS9ib29rZV9lbXVsYXRlLmMNCj4gQEAgLTI2LDYgKzI2LDcgQEAN
Cj4gICNkZWZpbmUgT1BfMTlfWE9QX1JGTUNJICAgMzgNCj4gICNkZWZpbmUgT1BfMTlfWE9QX1JG
SSAgICAgNTANCj4gICNkZWZpbmUgT1BfMTlfWE9QX1JGQ0kgICAgNTENCj4gKyNkZWZpbmUgT1Bf
MTlfWE9QX1JGREkgICAgMzkNCj4gDQo+ICAjZGVmaW5lIE9QXzMxX1hPUF9NRk1TUiAgIDgzDQo+
ICAjZGVmaW5lIE9QXzMxX1hPUF9XUlRFRSAgIDEzMQ0KPiBAQCAtMzgsMTAgKzM5LDI0IEBAIHN0
YXRpYyB2b2lkIGt2bXBwY19lbXVsX3JmaShzdHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUpDQo+ICAJa3Zt
cHBjX3NldF9tc3IodmNwdSwgdmNwdS0+YXJjaC5zaGFyZWQtPnNycjEpOyAgfQ0KPiANCj4gK3N0
YXRpYyB2b2lkIGt2bXBwY19lbXVsX3JmZGkoc3RydWN0IGt2bV92Y3B1ICp2Y3B1KSB7DQo+ICsJ
dmNwdS0+YXJjaC5wYyA9IHZjcHUtPmFyY2guZHNycjA7DQo+ICsJLyogRm9yY2UgTVNSX0RFIHdo
ZW4gZ3Vlc3QgZG9lcyBub3Qgb3duIGRlYnVnIGZhY2lsaXRpZXMgKi8NCj4gKwlpZiAodmNwdS0+
Z3Vlc3RfZGVidWcpDQo+ICsJCWt2bXBwY19zZXRfbXNyKHZjcHUsIHZjcHUtPmFyY2guZHNycjEg
fCBNU1JfREUpOw0KPiArCWVsc2UNCj4gKwkJa3ZtcHBjX3NldF9tc3IodmNwdSwgdmNwdS0+YXJj
aC5kc3JyMSk7IH0NCj4gKw0KPiAgc3RhdGljIHZvaWQga3ZtcHBjX2VtdWxfcmZjaShzdHJ1Y3Qg
a3ZtX3ZjcHUgKnZjcHUpICB7DQo+ICAJdmNwdS0+YXJjaC5wYyA9IHZjcHUtPmFyY2guY3NycjA7
DQo+IC0Ja3ZtcHBjX3NldF9tc3IodmNwdSwgdmNwdS0+YXJjaC5jc3JyMSk7DQo+ICsJLyogRm9y
Y2UgTVNSX0RFIHdoZW4gZ3Vlc3QgZG9lcyBub3Qgb3duIGRlYnVnIGZhY2lsaXRpZXMgKi8NCj4g
KwlpZiAodmNwdS0+Z3Vlc3RfZGVidWcpDQo+ICsJCWt2bXBwY19zZXRfbXNyKHZjcHUsIHZjcHUt
PmFyY2guY3NycjEgfCBNU1JfREUpOw0KPiArCWVsc2UNCj4gKwkJa3ZtcHBjX3NldF9tc3IodmNw
dSwgdmNwdS0+YXJjaC5jc3JyMSk7DQo+ICB9DQo+IA0KPiAgc3RhdGljIHZvaWQga3ZtcHBjX2Vt
dWxfcmZtY2koc3RydWN0IGt2bV92Y3B1ICp2Y3B1KSBAQCAtNzgsNiArOTMsMTIgQEAgaW50DQo+
IGt2bXBwY19ib29rZV9lbXVsYXRlX29wKHN0cnVjdCBrdm1fcnVuICpydW4sIHN0cnVjdCBrdm1f
dmNwdSAqdmNwdSwNCj4gIAkJCSphZHZhbmNlID0gMDsNCj4gIAkJCWJyZWFrOw0KPiANCj4gKwkJ
Y2FzZSBPUF8xOV9YT1BfUkZESToNCj4gKwkJCWt2bXBwY19lbXVsX3JmZGkodmNwdSk7DQo+ICsv
LwkJCWt2bXBwY19zZXRfZXhpdF90eXBlKHZjcHUsIEVNVUxBVEVEX1JGRElfRVhJVFMpOw0KPiAr
CQkJKmFkdmFuY2UgPSAwOw0KPiArCQkJYnJlYWs7DQo+ICsNCj4gIAkJZGVmYXVsdDoNCj4gIAkJ
CWVtdWxhdGVkID0gRU1VTEFURV9GQUlMOw0KPiAgCQkJYnJlYWs7DQo+IEBAIC0xMzEsNiArMTUy
LDcgQEAgaW50IGt2bXBwY19ib29rZV9lbXVsYXRlX29wKHN0cnVjdCBrdm1fcnVuICpydW4sIHN0
cnVjdA0KPiBrdm1fdmNwdSAqdmNwdSwgIGludCBrdm1wcGNfYm9va2VfZW11bGF0ZV9tdHNwcihz
dHJ1Y3Qga3ZtX3ZjcHUgKnZjcHUsIGludCBzcHJuLA0KPiB1bG9uZyBzcHJfdmFsKSAgew0KPiAg
CWludCBlbXVsYXRlZCA9IEVNVUxBVEVfRE9ORTsNCj4gKwlib29sIGRlYnVnX2luc3QgPSBmYWxz
ZTsNCj4gDQo+ICAJc3dpdGNoIChzcHJuKSB7DQo+ICAJY2FzZSBTUFJOX0RFQVI6DQo+IEBAIC0x
NDUsMjEgKzE2Nyw3NCBAQCBpbnQga3ZtcHBjX2Jvb2tlX2VtdWxhdGVfbXRzcHIoc3RydWN0IGt2
bV92Y3B1ICp2Y3B1LCBpbnQNCj4gc3BybiwgdWxvbmcgc3ByX3ZhbCkNCj4gIAljYXNlIFNQUk5f
Q1NSUjE6DQo+ICAJCXZjcHUtPmFyY2guY3NycjEgPSBzcHJfdmFsOw0KPiAgCQlicmVhazsNCj4g
LQljYXNlIFNQUk5fREJDUjA6DQo+IC0JCXZjcHUtPmFyY2guZGJnX3JlZy5kYmNyMCA9IHNwcl92
YWw7DQo+ICsJY2FzZSBTUFJOX0RTUlIwOg0KPiArCQl2Y3B1LT5hcmNoLmRzcnIwID0gc3ByX3Zh
bDsNCj4gIAkJYnJlYWs7DQo+IC0JY2FzZSBTUFJOX0RCQ1IxOg0KPiAtCQl2Y3B1LT5hcmNoLmRi
Z19yZWcuZGJjcjEgPSBzcHJfdmFsOw0KPiArCWNhc2UgU1BSTl9EU1JSMToNCj4gKwkJdmNwdS0+
YXJjaC5kc3JyMSA9IHNwcl92YWw7DQo+ICsJCWJyZWFrOw0KPiArCWNhc2UgU1BSTl9JQUMxOg0K
PiArCQlkZWJ1Z19pbnN0ID0gdHJ1ZTsNCj4gKwkJdmNwdS0+YXJjaC5kYmdfcmVnLmlhYzEgPSBz
cHJfdmFsOw0KPiArCQl2Y3B1LT5hcmNoLnNoYWRvd19kYmdfcmVnLmlhYzEgPSBzcHJfdmFsOw0K
PiArCQlicmVhazsNCj4gKwljYXNlIFNQUk5fSUFDMjoNCj4gKwkJZGVidWdfaW5zdCA9IHRydWU7
DQo+ICsJCXZjcHUtPmFyY2guZGJnX3JlZy5pYWMyID0gc3ByX3ZhbDsNCj4gKwkJdmNwdS0+YXJj
aC5zaGFkb3dfZGJnX3JlZy5pYWMyID0gc3ByX3ZhbDsNCj4gKwkJYnJlYWs7DQo+ICsjaWZuZGVm
IENPTkZJR19QUENfRlNMX0JPT0szRQ0KPiArCWNhc2UgU1BSTl9JQUMzOg0KPiArCQlkZWJ1Z19p
bnN0ID0gdHJ1ZTsNCj4gKwkJdmNwdS0+YXJjaC5kYmdfcmVnLmlhYzMgPSBzcHJfdmFsOw0KPiAr
CQl2Y3B1LT5hcmNoLnNoYWRvd19kYmdfcmVnLmlhYzMgPSBzcHJfdmFsOw0KPiAgCQlicmVhazsN
Cj4gKwljYXNlIFNQUk5fSUFDNDoNCj4gKwkJZGVidWdfaW5zdCA9IHRydWU7DQo+ICsJCXZjcHUt
PmFyY2guZGJnX3JlZy5pYWM0ID0gc3ByX3ZhbDsNCj4gKwkJdmNwdS0+YXJjaC5zaGFkb3dfZGJn
X3JlZy5pYWM0ID0gc3ByX3ZhbDsNCj4gKwkJYnJlYWs7DQo+ICsjZW5kaWYNCj4gKwljYXNlIFNQ
Uk5fREFDMToNCj4gKwkJZGVidWdfaW5zdCA9IHRydWU7DQo+ICsJCXZjcHUtPmFyY2guZGJnX3Jl
Zy5kYWMxID0gc3ByX3ZhbDsNCj4gKwkJdmNwdS0+YXJjaC5zaGFkb3dfZGJnX3JlZy5kYWMxID0g
c3ByX3ZhbDsNCj4gKwkJYnJlYWs7DQo+ICsJY2FzZSBTUFJOX0RBQzI6DQo+ICsJCWRlYnVnX2lu
c3QgPSB0cnVlOw0KPiArCQl2Y3B1LT5hcmNoLmRiZ19yZWcuZGFjMiA9IHNwcl92YWw7DQo+ICsJ
CXZjcHUtPmFyY2guc2hhZG93X2RiZ19yZWcuZGFjMiA9IHNwcl92YWw7DQo+ICsJCWJyZWFrOw0K
PiArIAljYXNlIFNQUk5fREJDUjA6DQo+ICsJCWRlYnVnX2luc3QgPSB0cnVlOw0KPiArCQlzcHJf
dmFsICY9IChEQkNSMF9JRE0gfCBEQkNSMF9JQyB8IERCQ1IwX0JUIHwgREJDUjBfVElFIHwNCj4g
KwkJCURCQ1IwX0lBQzEgfCBEQkNSMF9JQUMyIHwgREJDUjBfSUFDMyB8IERCQ1IwX0lBQzQgIHwN
Cj4gKwkJCURCQ1IwX0RBQzFSIHwgREJDUjBfREFDMVcgfCBEQkNSMF9EQUMyUiB8IERCQ1IwX0RB
QzJXKTsNCj4gKw0KPiArIAkJdmNwdS0+YXJjaC5kYmdfcmVnLmRiY3IwID0gc3ByX3ZhbDsNCj4g
KwkJdmNwdS0+YXJjaC5zaGFkb3dfZGJnX3JlZy5kYmNyMCA9IHNwcl92YWw7DQo+ICsgCQlicmVh
azsNCj4gKyAJY2FzZSBTUFJOX0RCQ1IxOg0KPiArCQlkZWJ1Z19pbnN0ID0gdHJ1ZTsNCj4gKyAJ
CXZjcHUtPmFyY2guZGJnX3JlZy5kYmNyMSA9IHNwcl92YWw7DQo+ICsJCXZjcHUtPmFyY2guc2hh
ZG93X2RiZ19yZWcuZGJjcjEgPSBzcHJfdmFsOw0KPiArCQlicmVhazsNCj4gKwljYXNlIFNQUk5f
REJDUjI6DQo+ICsJCWRlYnVnX2luc3QgPSB0cnVlOw0KPiArCQl2Y3B1LT5hcmNoLmRiZ19yZWcu
ZGJjcjIgPSBzcHJfdmFsOw0KPiArCQl2Y3B1LT5hcmNoLnNoYWRvd19kYmdfcmVnLmRiY3IyID0g
c3ByX3ZhbDsNCj4gKyAJCWJyZWFrOw0KPiArIAljYXNlIFNQUk5fREJTUjoNCj4gKyAJCXZjcHUt
PmFyY2guZGJzciAmPSB+c3ByX3ZhbDsNCj4gKwkJaWYgKHZjcHUtPmFyY2guZGJzciA9PSAwKQ0K
PiArCQkJa3ZtcHBjX2NvcmVfZGVxdWV1ZV9kZWJ1Zyh2Y3B1KTsNCj4gKyAJCWJyZWFrOw0KPiAg
CWNhc2UgU1BSTl9NQ1NSUjA6DQo+ICAJCXZjcHUtPmFyY2gubWNzcnIwID0gc3ByX3ZhbDsNCj4g
IAkJYnJlYWs7DQo+ICAJY2FzZSBTUFJOX01DU1JSMToNCj4gIAkJdmNwdS0+YXJjaC5tY3NycjEg
PSBzcHJfdmFsOw0KPiAgCQlicmVhazsNCj4gLQljYXNlIFNQUk5fREJTUjoNCj4gLQkJdmNwdS0+
YXJjaC5kYnNyICY9IH5zcHJfdmFsOw0KPiAtCQlicmVhazsNCj4gIAljYXNlIFNQUk5fVFNSOg0K
PiAgCQlrdm1wcGNfY2xyX3Rzcl9iaXRzKHZjcHUsIHNwcl92YWwpOw0KPiAgCQlicmVhazsNCj4g
QEAgLTI3MSw2ICszNDYsMTAgQEAgaW50IGt2bXBwY19ib29rZV9lbXVsYXRlX210c3ByKHN0cnVj
dCBrdm1fdmNwdSAqdmNwdSwgaW50DQo+IHNwcm4sIHVsb25nIHNwcl92YWwpDQo+ICAJCWVtdWxh
dGVkID0gRU1VTEFURV9GQUlMOw0KPiAgCX0NCj4gDQo+ICsJaWYgKGRlYnVnX2luc3QpIHsNCj4g
KwkJc3dpdGNoX2Jvb2tlX2RlYnVnX3JlZ3MoJnZjcHUtPmFyY2guc2hhZG93X2RiZ19yZWcpOw0K
PiArCQljdXJyZW50LT50aHJlYWQuZGVidWcgPSB2Y3B1LT5hcmNoLnNoYWRvd19kYmdfcmVnOw0K
PiArCX0NCj4gIAlyZXR1cm4gZW11bGF0ZWQ7DQo+ICB9DQo+IA0KPiBAQCAtMjk3LDEyICszNzYs
NDEgQEAgaW50IGt2bXBwY19ib29rZV9lbXVsYXRlX21mc3ByKHN0cnVjdCBrdm1fdmNwdSAqdmNw
dSwgaW50DQo+IHNwcm4sIHVsb25nICpzcHJfdmFsKQ0KPiAgCWNhc2UgU1BSTl9DU1JSMToNCj4g
IAkJKnNwcl92YWwgPSB2Y3B1LT5hcmNoLmNzcnIxOw0KPiAgCQlicmVhazsNCj4gKwljYXNlIFNQ
Uk5fRFNSUjA6DQo+ICsJCSpzcHJfdmFsID0gdmNwdS0+YXJjaC5kc3JyMDsNCj4gKwkJYnJlYWs7
DQo+ICsJY2FzZSBTUFJOX0RTUlIxOg0KPiArCQkqc3ByX3ZhbCA9IHZjcHUtPmFyY2guZHNycjE7
DQo+ICsJCWJyZWFrOw0KPiArCWNhc2UgU1BSTl9JQUMxOg0KPiArCQkqc3ByX3ZhbCA9IHZjcHUt
PmFyY2guZGJnX3JlZy5pYWMxOw0KPiArCQlicmVhazsNCj4gKwljYXNlIFNQUk5fSUFDMjoNCj4g
KwkJKnNwcl92YWwgPSB2Y3B1LT5hcmNoLmRiZ19yZWcuaWFjMjsNCj4gKwkJYnJlYWs7DQo+ICsj
aWZuZGVmIENPTkZJR19QUENfRlNMX0JPT0szRQ0KPiArCWNhc2UgU1BSTl9JQUMzOg0KPiArCQkq
c3ByX3ZhbCA9IHZjcHUtPmFyY2guZGJnX3JlZy5pYWMzOw0KPiArCQlicmVhazsNCj4gKwljYXNl
IFNQUk5fSUFDNDoNCj4gKwkJKnNwcl92YWwgPSB2Y3B1LT5hcmNoLmRiZ19yZWcuaWFjNDsNCj4g
KwkJYnJlYWs7DQo+ICsjZW5kaWYNCj4gKwljYXNlIFNQUk5fREFDMToNCj4gKwkJKnNwcl92YWwg
PSB2Y3B1LT5hcmNoLmRiZ19yZWcuZGFjMTsNCj4gKwkJYnJlYWs7DQo+ICsJY2FzZSBTUFJOX0RB
QzI6DQo+ICsJCSpzcHJfdmFsID0gdmNwdS0+YXJjaC5kYmdfcmVnLmRhYzI7DQo+ICsJCWJyZWFr
Ow0KPiAgCWNhc2UgU1BSTl9EQkNSMDoNCj4gIAkJKnNwcl92YWwgPSB2Y3B1LT5hcmNoLmRiZ19y
ZWcuZGJjcjA7DQo+ICAJCWJyZWFrOw0KPiAgCWNhc2UgU1BSTl9EQkNSMToNCj4gIAkJKnNwcl92
YWwgPSB2Y3B1LT5hcmNoLmRiZ19yZWcuZGJjcjE7DQo+ICAJCWJyZWFrOw0KPiArCWNhc2UgU1BS
Tl9EQkNSMjoNCj4gKwkJKnNwcl92YWwgPSB2Y3B1LT5hcmNoLmRiZ19yZWcuZGJjcjI7DQo+ICsJ
CWJyZWFrOw0KPiAgCWNhc2UgU1BSTl9NQ1NSUjA6DQo+ICAJCSpzcHJfdmFsID0gdmNwdS0+YXJj
aC5tY3NycjA7DQo+ICAJCWJyZWFrOw0KPiBkaWZmIC0tZ2l0IGEvYXJjaC9wb3dlcnBjL2t2bS9l
NTAwbWMuYyBiL2FyY2gvcG93ZXJwYy9rdm0vZTUwMG1jLmMgaW5kZXgNCj4gYmJmN2NkZC4uNTYw
YjU3NiAxMDA2NDQNCj4gLS0tIGEvYXJjaC9wb3dlcnBjL2t2bS9lNTAwbWMuYw0KPiArKysgYi9h
cmNoL3Bvd2VycGMva3ZtL2U1MDBtYy5jDQo+IEBAIC0yNDksNyArMjQ5LDcgQEAgaW50IGt2bXBw
Y19jb3JlX3ZjcHVfc2V0dXAoc3RydWN0IGt2bV92Y3B1ICp2Y3B1KSAgI2lmZGVmDQo+IENPTkZJ
R182NEJJVA0KPiAgCXZjcHUtPmFyY2guc2hhZG93X2VwY3IgfD0gU1BSTl9FUENSX0lDTTsgICNl
bmRpZg0KPiAtCXZjcHUtPmFyY2guc2hhZG93X21zcnAgPSBNU1JQX1VDTEVQIHwgTVNSUF9ERVAg
fCBNU1JQX1BNTVA7DQo+ICsJdmNwdS0+YXJjaC5zaGFkb3dfbXNycCA9IE1TUlBfVUNMRVAgfCBN
U1JQX1BNTVA7DQo+IA0KPiAgCXZjcHUtPmFyY2gucHZyID0gbWZzcHIoU1BSTl9QVlIpOw0KPiAg
CXZjcHVfZTUwMC0+c3ZyID0gbWZzcHIoU1BSTl9TVlIpOw0KPiANCj4gDQo+IC0tLS0tLS0tLS0t
LS0tLS0tLQ0KPiANCj4gVGhhbmtzDQo+IC1CaGFyYXQNCj4gDQo+ID4NCj4gPiAtU2NvdHQNCj4g
Pg0KDQo

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

On 02.07.14 19:28, Bharat.Bhushan@freescale.com wrote:
>
>> -----Original Message-----
>> From: Bhushan Bharat-R65777
>> Sent: Wednesday, July 02, 2014 5:07 PM
>> To: Wood Scott-B07421; Alexander Graf
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>> Subject: RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>> guest
>>
>>
>>> -----Original Message-----
>>> From: Wood Scott-B07421
>>> Sent: Tuesday, July 01, 2014 10:11 PM
>>> To: Alexander Graf
>>> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org;
>>> kvm@vger.kernel.org
>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
>>> injection to guest
>>>
>>> On Tue, 2014-07-01 at 18:22 +0200, Alexander Graf wrote:
>>>> On 01.07.14 17:35, Scott Wood wrote:
>>>>> On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
>>>>>> On 01.07.14 16:58, Scott Wood wrote:
>>>>>>> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
>>>>>>>> I don't think QEMU should be aware of these limitations.
>>>>>>> OK, but we should at least have some idea of how the whole thing
>>>>>>> is supposed to work, in order to determine if this is the
>>>>>>> correct behavior for QEMU.  I thought the model was that debug
>>>>>>> resources are either owned by QEMU or by the guest, and in the
>>>>>>> latter case, QEMU would never see the debug exception to begin with.
>>>>>> That's bad for a number of reasons. For starters it's different
>>>>>> from how
>>>>>> x86 handles debug registers - and I hate to be different just for
>>>>>> the sake of being different.
>>>>> How does it work on x86?
>>>> It overwrites more-or-less random breakpoints with its own ones, but
>>>> leaves the others intact ;).
>>> Are you talking about software breakpoints or management of hardware
>>> debug registers?
>>>
>>>>>> So if we do want to declare that debug registers are owned by
>>>>>> either QEMU or the guest, we should change the semantics for all
>>>>>> architectures.
>>>>> If we want to say that ownership of the registers is shared, we
>>>>> need a plan for how that would actually work.
>>>> I think you're overengineering here :). When do people actually use
>>>> gdbstub? Usually when they want to debug a broken guest. We can
>>>> either
>>>>
>>>>     * overengineer heavily and reduce the number of registers
>>>> available to the guest to always have spares
>>>>     * overengineer a bit and turn off guest debugging completely when
>>>> we use gdbstub
>>>>     * just leave as much alive as we can, hoping that it helps with
>>>> the debugging
>>>>
>>>> Option 3 is what x86 does - and I think it's a reasonable approach.
>>>> This is not an interface that needs to be 100% consistent and bullet
>>>> proof, it's a best effort to enable you to debug as much as possible.
>>> I'm not insisting on 100% -- just hoping for some
>>> explanation/discussion about how it's intended to work for the cases where it
>> can.
>>> How will MSR[DE] and MSRP[DEP] be handled?
>>>
>>> How would I go about telling QEMU/KVM that I don't want this shared
>>> mode, because I don't want guest to interfere with the debugging I'm
>>> trying to do from QEMU?
>>>
>>> Will guest accesses to debug registers cause a userspace exit when
>>> guest_debug is enabled?
>>>
>>>>>> I think we're in a path that is slow enough already to not worry
>>>>>> about performance.
>>>>> It's not just about performance, but simplicity of use, and
>>>>> consistency of API.
>>>>>
>>>>> Oh, and it looks like there already exist one reg definitions and
>>>>> implementations for most of the debug registers.
>>>> For BookE? Where?
>>> arch/powerpc/kvm/booke.c: KVM_REG_PPC_IACn, KVM_REG_PPC_DACn
>> I tried to quickly prototype what I think we want to do (this is not tested)
> Hi Scott,
>
> There is one problem which is stopping us to share debug resource between qemu and guest, looking for suggestions:
> - As qemu is also using debug resource,  We have to set MSR_DE and set MSRP_DEP (guest will not be able to clear MSR_DE). So qemu set debug events will always cause the debug interrupts.
> - Now guest is also using debug resources and for some reason if guest wants to clear MSR_DE (disable debug interrupt) But it will not be able to disable as MSRP_DEP is set and KVM will not come to know guest willingness to disable MSR_DE.
> - If the debug interrupts occurs then we will exit to QEMU and this may not a QEMU set event so it will inject interrupt to guest (using one-reg or set-sregs)
> - Now KVM, when handling one-reg/sregs request to inject debug interrupt, do not know whether guest can handle the debug interrupt or not (as guest might have tried to set/clear MSR_DE).

Yeah, and with this everything falls apart. I guess we can't share 
hardware debug resources after all then. So yes, let's declare all 
hardware debug facilities QEMU owned as soon as QEMU starts using gdbstub.


Alex

Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to guest

[Alexander Graf]

On 02.07.14 19:28, Bharat.Bhushan@freescale.com wrote:
>
>> -----Original Message-----
>> From: Bhushan Bharat-R65777
>> Sent: Wednesday, July 02, 2014 5:07 PM
>> To: Wood Scott-B07421; Alexander Graf
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>> Subject: RE: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt injection to
>> guest
>>
>>
>>> -----Original Message-----
>>> From: Wood Scott-B07421
>>> Sent: Tuesday, July 01, 2014 10:11 PM
>>> To: Alexander Graf
>>> Cc: Bhushan Bharat-R65777; kvm-ppc@vger.kernel.org;
>>> kvm@vger.kernel.org
>>> Subject: Re: [PATCH 2/2] KVM : powerpc/booke: Allow debug interrupt
>>> injection to guest
>>>
>>> On Tue, 2014-07-01 at 18:22 +0200, Alexander Graf wrote:
>>>> On 01.07.14 17:35, Scott Wood wrote:
>>>>> On Tue, 2014-07-01 at 17:04 +0200, Alexander Graf wrote:
>>>>>> On 01.07.14 16:58, Scott Wood wrote:
>>>>>>> On Tue, 2014-07-01 at 08:23 +0200, Alexander Graf wrote:
>>>>>>>> I don't think QEMU should be aware of these limitations.
>>>>>>> OK, but we should at least have some idea of how the whole thing
>>>>>>> is supposed to work, in order to determine if this is the
>>>>>>> correct behavior for QEMU.  I thought the model was that debug
>>>>>>> resources are either owned by QEMU or by the guest, and in the
>>>>>>> latter case, QEMU would never see the debug exception to begin with.
>>>>>> That's bad for a number of reasons. For starters it's different
>>>>>> from how
>>>>>> x86 handles debug registers - and I hate to be different just for
>>>>>> the sake of being different.
>>>>> How does it work on x86?
>>>> It overwrites more-or-less random breakpoints with its own ones, but
>>>> leaves the others intact ;).
>>> Are you talking about software breakpoints or management of hardware
>>> debug registers?
>>>
>>>>>> So if we do want to declare that debug registers are owned by
>>>>>> either QEMU or the guest, we should change the semantics for all
>>>>>> architectures.
>>>>> If we want to say that ownership of the registers is shared, we
>>>>> need a plan for how that would actually work.
>>>> I think you're overengineering here :). When do people actually use
>>>> gdbstub? Usually when they want to debug a broken guest. We can
>>>> either
>>>>
>>>>     * overengineer heavily and reduce the number of registers
>>>> available to the guest to always have spares
>>>>     * overengineer a bit and turn off guest debugging completely when
>>>> we use gdbstub
>>>>     * just leave as much alive as we can, hoping that it helps with
>>>> the debugging
>>>>
>>>> Option 3 is what x86 does - and I think it's a reasonable approach.
>>>> This is not an interface that needs to be 100% consistent and bullet
>>>> proof, it's a best effort to enable you to debug as much as possible.
>>> I'm not insisting on 100% -- just hoping for some
>>> explanation/discussion about how it's intended to work for the cases where it
>> can.
>>> How will MSR[DE] and MSRP[DEP] be handled?
>>>
>>> How would I go about telling QEMU/KVM that I don't want this shared
>>> mode, because I don't want guest to interfere with the debugging I'm
>>> trying to do from QEMU?
>>>
>>> Will guest accesses to debug registers cause a userspace exit when
>>> guest_debug is enabled?
>>>
>>>>>> I think we're in a path that is slow enough already to not worry
>>>>>> about performance.
>>>>> It's not just about performance, but simplicity of use, and
>>>>> consistency of API.
>>>>>
>>>>> Oh, and it looks like there already exist one reg definitions and
>>>>> implementations for most of the debug registers.
>>>> For BookE? Where?
>>> arch/powerpc/kvm/booke.c: KVM_REG_PPC_IACn, KVM_REG_PPC_DACn
>> I tried to quickly prototype what I think we want to do (this is not tested)
> Hi Scott,
>
> There is one problem which is stopping us to share debug resource between qemu and guest, looking for suggestions:
> - As qemu is also using debug resource,  We have to set MSR_DE and set MSRP_DEP (guest will not be able to clear MSR_DE). So qemu set debug events will always cause the debug interrupts.
> - Now guest is also using debug resources and for some reason if guest wants to clear MSR_DE (disable debug interrupt) But it will not be able to disable as MSRP_DEP is set and KVM will not come to know guest willingness to disable MSR_DE.
> - If the debug interrupts occurs then we will exit to QEMU and this may not a QEMU set event so it will inject interrupt to guest (using one-reg or set-sregs)
> - Now KVM, when handling one-reg/sregs request to inject debug interrupt, do not know whether guest can handle the debug interrupt or not (as guest might have tried to set/clear MSR_DE).

Yeah, and with this everything falls apart. I guess we can't share 
hardware debug resources after all then. So yes, let's declare all 
hardware debug facilities QEMU owned as soon as QEMU starts using gdbstub.


Alex