All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoffer Dall <christoffer.dall@linaro.org>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, marc.zyngier@arm.com,
	peter.maydell@linaro.org, agraf@suse.de, drjones@redhat.com,
	pbonzini@redhat.com, zhichao.huang@linaro.org,
	jan.kiszka@siemens.com, dahi@linux.vnet.ibm.com,
	r65777@freescale.com, bp@suse.de, Gleb Natapov <gleb@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Russell King <linux@arm.linux.org.uk>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support
Date: Tue, 14 Apr 2015 10:25:58 +0200	[thread overview]
Message-ID: <20150414082558.GS6186@cbox> (raw)
In-Reply-To: <1427814488-28467-7-git-send-email-alex.bennee@linaro.org>

On Tue, Mar 31, 2015 at 04:08:04PM +0100, Alex Bennée wrote:
> This adds support for SW breakpoints inserted by userspace.
> 
> We do this by trapping all BKPT exceptions in the
> hypervisor (MDCR_EL2_TDE).

you mean trapping all exceptions in the guest to the hypervisor?

> The kvm_debug_exit_arch carries the address
> of the exception.

why?  can userspace not simply read out the PC using GET_ONE_REG?

> If user-space doesn't know of the breakpoint then we
> have a guest inserted breakpoint and the hypervisor needs to start again
> and deliver the exception to guest.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> 
> ---
> v2
>   - update to use new exit struct
>   - tweak for C setup
>   - do our setup in debug_setup/clear code
>   - fixed up comments
> 
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 06c5064..17d4f9c 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2626,7 +2626,7 @@ when running. Common control bits are:
>  The top 16 bits of the control field are architecture specific control
>  flags which can include the following:
>  
> -  - KVM_GUESTDBG_USE_SW_BP:     using software breakpoints [x86]
> +  - KVM_GUESTDBG_USE_SW_BP:     using software breakpoints [x86, arm64]
>    - KVM_GUESTDBG_USE_HW_BP:     using hardware breakpoints [x86, s390]
>    - KVM_GUESTDBG_INJECT_DB:     inject DB type exception [x86]
>    - KVM_GUESTDBG_INJECT_BP:     inject BP type exception [x86]
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 7ea8b0e..d3bc8dc 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -304,7 +304,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
>  	kvm_arm_set_running_vcpu(NULL);
>  }
>  
> -#define KVM_GUESTDBG_VALID (KVM_GUESTDBG_ENABLE)
> +#define KVM_GUESTDBG_VALID (KVM_GUESTDBG_ENABLE|KVM_GUESTDBG_USE_SW_BP)

nit: spaces around the operator

>  
>  int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>  					struct kvm_guest_debug *dbg)
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index 8a29d0b..cff0475 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -45,11 +45,18 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
>  	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM | MDCR_EL2_TPMCR);
>  	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TDRA | MDCR_EL2_TDOSA);
>  
> +	/* Trap debug register access? */

other patch

>  	if (!vcpu->arch.debug_flags & KVM_ARM64_DEBUG_DIRTY)
>  		vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA;
>  	else
>  		vcpu->arch.mdcr_el2 &= ~MDCR_EL2_TDA;
>  
> +	/* Trap breakpoints? */
> +	if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP)
> +		vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE;
> +	else
> +		vcpu->arch.mdcr_el2 &= ~MDCR_EL2_TDE;

so now you're trapping all debug exceptions, right?

what happens if the guest is using the hardware to debug debug stuff and
generates other kinds of debug exceptions, like a hardware breakpoint,
will we not see an unhandled exception and the guest being forcefully
killed?

> +
>  }
>  
>  void kvm_arch_clear_debug(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 524fa25..ed1bbb4 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -82,6 +82,37 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  	return 1;
>  }
>  
> +/**
> + * kvm_handle_debug_exception - handle a debug exception instruction

handle a software breadkpoint exception

> + *
> + * @vcpu:	the vcpu pointer
> + * @run:	access to the kvm_run structure for results
> + *
> + * We route all debug exceptions through the same handler as we

all debug exceptions?  software breakpoints and all?  then why the above
shot text?

> + * just need to report the PC and the HSR values to userspace.
> + * Userspace may decide to re-inject the exception and deliver it to
> + * the guest if it wasn't for the host to deal with.

now I'm confused - does userspace setup the guest to receive an
exception or does it tell KVM to emulate an exception for the guest or
do we execute the breakpoint without trapping the debug exception?

> + */
> +static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +{
> +	u32 hsr = kvm_vcpu_get_hsr(vcpu);
> +
> +	run->exit_reason = KVM_EXIT_DEBUG;
> +	run->debug.arch.hsr = hsr;
> +
> +	switch (hsr >> ESR_ELx_EC_SHIFT) {
> +	case ESR_ELx_EC_BKPT32:
> +	case ESR_ELx_EC_BRK64:
> +		run->debug.arch.pc = *vcpu_pc(vcpu);
> +		break;
> +	default:
> +		kvm_err("%s: un-handled case hsr: %#08x\n",
> +			__func__, (unsigned int) hsr);

this should never happen right?

> +		break;
> +	}
> +	return 0;
> +}
> +
>  static exit_handle_fn arm_exit_handlers[] = {
>  	[ESR_ELx_EC_WFx]	= kvm_handle_wfx,
>  	[ESR_ELx_EC_CP15_32]	= kvm_handle_cp15_32,
> @@ -96,6 +127,8 @@ static exit_handle_fn arm_exit_handlers[] = {
>  	[ESR_ELx_EC_SYS64]	= kvm_handle_sys_reg,
>  	[ESR_ELx_EC_IABT_LOW]	= kvm_handle_guest_abort,
>  	[ESR_ELx_EC_DABT_LOW]	= kvm_handle_guest_abort,
> +	[ESR_ELx_EC_BKPT32]	= kvm_handle_guest_debug,
> +	[ESR_ELx_EC_BRK64]	= kvm_handle_guest_debug,
>  };
>  
>  static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
> -- 
> 2.3.4
> 

WARNING: multiple messages have this Message-ID (diff)
From: christoffer.dall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support
Date: Tue, 14 Apr 2015 10:25:58 +0200	[thread overview]
Message-ID: <20150414082558.GS6186@cbox> (raw)
In-Reply-To: <1427814488-28467-7-git-send-email-alex.bennee@linaro.org>

On Tue, Mar 31, 2015 at 04:08:04PM +0100, Alex Benn?e wrote:
> This adds support for SW breakpoints inserted by userspace.
> 
> We do this by trapping all BKPT exceptions in the
> hypervisor (MDCR_EL2_TDE).

you mean trapping all exceptions in the guest to the hypervisor?

> The kvm_debug_exit_arch carries the address
> of the exception.

why?  can userspace not simply read out the PC using GET_ONE_REG?

> If user-space doesn't know of the breakpoint then we
> have a guest inserted breakpoint and the hypervisor needs to start again
> and deliver the exception to guest.
> 
> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
> 
> ---
> v2
>   - update to use new exit struct
>   - tweak for C setup
>   - do our setup in debug_setup/clear code
>   - fixed up comments
> 
> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> index 06c5064..17d4f9c 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -2626,7 +2626,7 @@ when running. Common control bits are:
>  The top 16 bits of the control field are architecture specific control
>  flags which can include the following:
>  
> -  - KVM_GUESTDBG_USE_SW_BP:     using software breakpoints [x86]
> +  - KVM_GUESTDBG_USE_SW_BP:     using software breakpoints [x86, arm64]
>    - KVM_GUESTDBG_USE_HW_BP:     using hardware breakpoints [x86, s390]
>    - KVM_GUESTDBG_INJECT_DB:     inject DB type exception [x86]
>    - KVM_GUESTDBG_INJECT_BP:     inject BP type exception [x86]
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 7ea8b0e..d3bc8dc 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -304,7 +304,7 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
>  	kvm_arm_set_running_vcpu(NULL);
>  }
>  
> -#define KVM_GUESTDBG_VALID (KVM_GUESTDBG_ENABLE)
> +#define KVM_GUESTDBG_VALID (KVM_GUESTDBG_ENABLE|KVM_GUESTDBG_USE_SW_BP)

nit: spaces around the operator

>  
>  int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>  					struct kvm_guest_debug *dbg)
> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c
> index 8a29d0b..cff0475 100644
> --- a/arch/arm64/kvm/debug.c
> +++ b/arch/arm64/kvm/debug.c
> @@ -45,11 +45,18 @@ void kvm_arch_setup_debug(struct kvm_vcpu *vcpu)
>  	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM | MDCR_EL2_TPMCR);
>  	vcpu->arch.mdcr_el2 |= (MDCR_EL2_TDRA | MDCR_EL2_TDOSA);
>  
> +	/* Trap debug register access? */

other patch

>  	if (!vcpu->arch.debug_flags & KVM_ARM64_DEBUG_DIRTY)
>  		vcpu->arch.mdcr_el2 |= MDCR_EL2_TDA;
>  	else
>  		vcpu->arch.mdcr_el2 &= ~MDCR_EL2_TDA;
>  
> +	/* Trap breakpoints? */
> +	if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP)
> +		vcpu->arch.mdcr_el2 |= MDCR_EL2_TDE;
> +	else
> +		vcpu->arch.mdcr_el2 &= ~MDCR_EL2_TDE;

so now you're trapping all debug exceptions, right?

what happens if the guest is using the hardware to debug debug stuff and
generates other kinds of debug exceptions, like a hardware breakpoint,
will we not see an unhandled exception and the guest being forcefully
killed?

> +
>  }
>  
>  void kvm_arch_clear_debug(struct kvm_vcpu *vcpu)
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index 524fa25..ed1bbb4 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -82,6 +82,37 @@ static int kvm_handle_wfx(struct kvm_vcpu *vcpu, struct kvm_run *run)
>  	return 1;
>  }
>  
> +/**
> + * kvm_handle_debug_exception - handle a debug exception instruction

handle a software breadkpoint exception

> + *
> + * @vcpu:	the vcpu pointer
> + * @run:	access to the kvm_run structure for results
> + *
> + * We route all debug exceptions through the same handler as we

all debug exceptions?  software breakpoints and all?  then why the above
shot text?

> + * just need to report the PC and the HSR values to userspace.
> + * Userspace may decide to re-inject the exception and deliver it to
> + * the guest if it wasn't for the host to deal with.

now I'm confused - does userspace setup the guest to receive an
exception or does it tell KVM to emulate an exception for the guest or
do we execute the breakpoint without trapping the debug exception?

> + */
> +static int kvm_handle_guest_debug(struct kvm_vcpu *vcpu, struct kvm_run *run)
> +{
> +	u32 hsr = kvm_vcpu_get_hsr(vcpu);
> +
> +	run->exit_reason = KVM_EXIT_DEBUG;
> +	run->debug.arch.hsr = hsr;
> +
> +	switch (hsr >> ESR_ELx_EC_SHIFT) {
> +	case ESR_ELx_EC_BKPT32:
> +	case ESR_ELx_EC_BRK64:
> +		run->debug.arch.pc = *vcpu_pc(vcpu);
> +		break;
> +	default:
> +		kvm_err("%s: un-handled case hsr: %#08x\n",
> +			__func__, (unsigned int) hsr);

this should never happen right?

> +		break;
> +	}
> +	return 0;
> +}
> +
>  static exit_handle_fn arm_exit_handlers[] = {
>  	[ESR_ELx_EC_WFx]	= kvm_handle_wfx,
>  	[ESR_ELx_EC_CP15_32]	= kvm_handle_cp15_32,
> @@ -96,6 +127,8 @@ static exit_handle_fn arm_exit_handlers[] = {
>  	[ESR_ELx_EC_SYS64]	= kvm_handle_sys_reg,
>  	[ESR_ELx_EC_IABT_LOW]	= kvm_handle_guest_abort,
>  	[ESR_ELx_EC_DABT_LOW]	= kvm_handle_guest_abort,
> +	[ESR_ELx_EC_BKPT32]	= kvm_handle_guest_debug,
> +	[ESR_ELx_EC_BRK64]	= kvm_handle_guest_debug,
>  };
>  
>  static exit_handle_fn kvm_get_exit_handler(struct kvm_vcpu *vcpu)
> -- 
> 2.3.4
> 

  parent reply	other threads:[~2015-04-14  8:25 UTC|newest]

Thread overview: 199+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-31 15:07 [PATCH v2 00/10] KVM Guest Debug support for arm64 Alex Bennée
2015-03-31 15:07 ` Alex Bennée
2015-03-31 15:07 ` [PATCH v2 01/10] KVM: add commentary for kvm_debug_exit_arch struct Alex Bennée
2015-03-31 15:07   ` Alex Bennée
2015-03-31 15:07   ` Alex Bennée
2015-04-01 15:38   ` David Hildenbrand
2015-04-01 15:38     ` David Hildenbrand
2015-04-01 15:38     ` David Hildenbrand
2015-04-01 15:38     ` David Hildenbrand
2015-04-10 12:58   ` Andrew Jones
2015-04-10 12:58     ` Andrew Jones
2015-04-13 10:57   ` Christoffer Dall
2015-04-13 10:57     ` Christoffer Dall
2015-04-13 10:57     ` Christoffer Dall
2015-03-31 15:08 ` [PATCH v2 02/10] KVM: define common __KVM_GUESTDBG_USE_SW/HW_BP values Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-04-10 12:59   ` Andrew Jones
2015-04-10 12:59     ` Andrew Jones
2015-04-10 12:59     ` Andrew Jones
2015-04-10 12:59     ` Andrew Jones
2015-04-13 11:55   ` Christoffer Dall
2015-04-13 11:55     ` Christoffer Dall
2015-04-13 11:55     ` Christoffer Dall
2015-04-13 11:55     ` Christoffer Dall
2015-04-13 14:51     ` Alex Bennée
2015-04-13 14:51       ` Alex Bennée
2015-04-13 14:51       ` Alex Bennée
2015-04-13 14:51       ` Alex Bennée
2015-04-13 15:07       ` Andrew Jones
2015-04-13 15:07         ` Andrew Jones
2015-04-13 15:07         ` Andrew Jones
2015-04-13 15:07         ` Andrew Jones
2015-04-14  8:24       ` Christoffer Dall
2015-04-14  8:24         ` Christoffer Dall
2015-04-14  8:24         ` Christoffer Dall
2015-04-14  8:24         ` Christoffer Dall
2015-04-14  8:24         ` Christoffer Dall
2015-03-31 15:08 ` [PATCH v2 03/10] KVM: arm: guest debug, define API headers Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-04-01 15:46   ` David Hildenbrand
2015-04-01 15:46     ` David Hildenbrand
2015-04-01 15:46     ` David Hildenbrand
2015-04-01 16:01     ` Alex Bennée
2015-04-01 16:01       ` Alex Bennée
2015-04-01 16:05       ` David Hildenbrand
2015-04-01 16:05         ` David Hildenbrand
2015-04-01 16:09       ` Peter Maydell
2015-04-01 16:09         ` Peter Maydell
2015-04-10 13:05   ` Andrew Jones
2015-04-10 13:05     ` Andrew Jones
2015-04-10 13:05     ` Andrew Jones
2015-04-13 12:08   ` Christoffer Dall
2015-04-13 12:08     ` Christoffer Dall
2015-04-23  9:54     ` Alex Bennée
2015-04-23  9:54       ` Alex Bennée
2015-04-23  9:54       ` Alex Bennée
2015-03-31 15:08 ` [PATCH v2 04/10] KVM: arm: guest debug, add stub KVM_SET_GUEST_DEBUG ioctl Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-04-01 15:55   ` David Hildenbrand
2015-04-01 15:55     ` David Hildenbrand
2015-04-01 15:55     ` David Hildenbrand
2015-04-09 12:28     ` Andrew Jones
2015-04-09 12:28       ` Andrew Jones
2015-04-09 12:28       ` Andrew Jones
2015-04-09 14:19       ` Alex Bennée
2015-04-09 14:19         ` Alex Bennée
2015-04-09 14:19         ` Alex Bennée
2015-04-13 12:12   ` Christoffer Dall
2015-04-13 12:12     ` Christoffer Dall
2015-04-13 12:12     ` Christoffer Dall
2015-04-14  6:31     ` David Hildenbrand
2015-04-14  6:31       ` David Hildenbrand
2015-04-14  6:31       ` David Hildenbrand
2015-04-14  8:03       ` Alex Bennée
2015-04-14  8:03         ` Alex Bennée
2015-04-14  8:03         ` Alex Bennée
2015-03-31 15:08 ` [PATCH v2 05/10] KVM: arm: introduce kvm_arch_setup/clear_debug() Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-04-01 16:28   ` David Hildenbrand
2015-04-01 16:28     ` David Hildenbrand
2015-04-01 16:28     ` David Hildenbrand
2015-04-09 12:56     ` Andrew Jones
2015-04-09 12:56       ` Andrew Jones
2015-04-09 12:56       ` Andrew Jones
2015-04-09 14:18       ` Alex Bennée
2015-04-09 14:18         ` Alex Bennée
2015-04-09 12:55   ` Andrew Jones
2015-04-09 12:55     ` Andrew Jones
2015-04-09 12:55     ` Andrew Jones
2015-04-13 14:36   ` Christoffer Dall
2015-04-13 14:36     ` Christoffer Dall
2015-04-13 14:48     ` Christoffer Dall
2015-04-13 14:48       ` Christoffer Dall
2015-04-13 14:48       ` Christoffer Dall
2015-04-13 15:29     ` Alex Bennée
2015-04-13 15:29       ` Alex Bennée
2015-04-13 15:29       ` Alex Bennée
2015-03-31 15:08 ` [PATCH v2 06/10] KVM: arm64: guest debug, add SW break point support Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-04-02 12:52   ` David Hildenbrand
2015-04-02 12:52     ` David Hildenbrand
2015-04-02 12:52     ` David Hildenbrand
2015-04-02 14:06     ` Alex Bennée
2015-04-02 14:06       ` Alex Bennée
2015-04-02 14:06       ` Alex Bennée
2015-04-10 13:09   ` Andrew Jones
2015-04-10 13:09     ` Andrew Jones
2015-04-10 13:09     ` Andrew Jones
2015-04-14  8:25   ` Christoffer Dall [this message]
2015-04-14  8:25     ` Christoffer Dall
2015-04-23 14:26     ` Alex Bennée
2015-04-23 14:26       ` Alex Bennée
2015-04-23 14:26       ` Alex Bennée
2015-04-27 20:04       ` Christoffer Dall
2015-04-27 20:04         ` Christoffer Dall
2015-04-27 21:57         ` Peter Maydell
2015-04-27 21:57           ` Peter Maydell
2015-04-28  8:42           ` Alex Bennée
2015-04-28  8:42             ` Alex Bennée
2015-04-28  8:42             ` Alex Bennée
2015-04-28  9:34             ` Peter Maydell
2015-04-28  9:34               ` Peter Maydell
2015-04-28 12:56               ` Christoffer Dall
2015-04-28 12:56                 ` Christoffer Dall
2015-04-28 14:37                 ` Alex Bennée
2015-04-28 14:37                   ` Alex Bennée
2015-04-28 14:37                   ` Alex Bennée
2015-04-29  8:10                   ` Christoffer Dall
2015-04-29  8:10                     ` Christoffer Dall
2015-04-29  9:18                     ` Alex Bennée
2015-04-29  9:18                       ` Alex Bennée
2015-04-29  9:18                       ` Alex Bennée
2015-04-29 10:38                       ` Christoffer Dall
2015-04-29 10:38                         ` Christoffer Dall
2015-04-29 15:08                         ` Alex Bennée
2015-04-29 15:08                           ` Alex Bennée
2015-04-29 15:08                           ` Alex Bennée
2015-04-29 19:20                           ` Christoffer Dall
2015-04-29 19:20                             ` Christoffer Dall
2015-04-21 14:42   ` Zhichao Huang
2015-04-22  9:46     ` Alex Bennée
2015-04-22  9:46       ` Alex Bennée
2015-04-22  9:46       ` Alex Bennée
2015-03-31 15:08 ` [PATCH v2 07/10] KVM: arm64: guest debug, add support for single-step Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-04-09 13:24   ` Andrew Jones
2015-04-09 13:24     ` Andrew Jones
2015-04-09 14:16     ` Alex Bennée
2015-04-09 14:16       ` Alex Bennée
2015-04-09 14:16       ` Alex Bennée
2015-04-14  8:27   ` Christoffer Dall
2015-04-14  8:27     ` Christoffer Dall
2015-04-14  8:27     ` Christoffer Dall
2015-03-31 15:08 ` [PATCH v2 08/10] KVM: arm64: guest debug, HW assisted debug support Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-04-10 12:25   ` Andrew Jones
2015-04-10 12:25     ` Andrew Jones
2015-04-10 12:25     ` Andrew Jones
2015-04-13  8:00     ` Alex Bennée
2015-04-13  8:00       ` Alex Bennée
2015-04-13  8:00       ` Alex Bennée
2015-04-14 10:23     ` Christoffer Dall
2015-04-14 10:23       ` Christoffer Dall
2015-04-14 10:17   ` Christoffer Dall
2015-04-14 10:17     ` Christoffer Dall
2015-04-14 10:17     ` Christoffer Dall
2015-03-31 15:08 ` [PATCH v2 09/10] KVM: arm64: trap nested debug register access Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-04-10 12:38   ` Andrew Jones
2015-04-10 12:38     ` Andrew Jones
2015-04-10 12:38     ` Andrew Jones
2015-04-13  7:59     ` Alex Bennée
2015-04-13  7:59       ` Alex Bennée
2015-04-13  7:59       ` Alex Bennée
2015-04-14 10:27       ` Christoffer Dall
2015-04-14 10:27         ` Christoffer Dall
2015-04-14 10:27         ` Christoffer Dall
2015-04-14 10:30   ` Christoffer Dall
2015-04-14 10:30     ` Christoffer Dall
2015-04-14 10:30     ` Christoffer Dall
2015-03-31 15:08 ` [PATCH v2 10/10] KVM: arm64: add trace points for guest_debug debug Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-03-31 15:08   ` Alex Bennée
2015-04-10 12:54   ` Andrew Jones
2015-04-10 12:54     ` Andrew Jones
2015-04-13  7:57     ` Alex Bennée
2015-04-13  7:57       ` Alex Bennée
2015-04-14 10:32   ` Christoffer Dall
2015-04-14 10:32     ` Christoffer Dall
2015-04-14 10:32     ` Christoffer Dall

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20150414082558.GS6186@cbox \
    --to=christoffer.dall@linaro.org \
    --cc=agraf@suse.de \
    --cc=alex.bennee@linaro.org \
    --cc=bp@suse.de \
    --cc=catalin.marinas@arm.com \
    --cc=corbet@lwn.net \
    --cc=dahi@linux.vnet.ibm.com \
    --cc=drjones@redhat.com \
    --cc=gleb@kernel.org \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=marc.zyngier@arm.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=r65777@freescale.com \
    --cc=will.deacon@arm.com \
    --cc=zhichao.huang@linaro.org \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.