All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Vivier <lvivier@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
	kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Cc: Gleb Natapov <gleb@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <agraf@suse.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	dgibson@redhat.com
Subject: Re: [PATCH] kvm-pr: manage single-step mode
Date: Fri, 08 Apr 2016 06:58:35 +0000	[thread overview]
Message-ID: <5707569B.1000704@redhat.com> (raw)
In-Reply-To: <57074E45.4040204@redhat.com>



On 08/04/2016 08:23, Thomas Huth wrote:
> On 22.03.2016 15:53, Laurent Vivier wrote:
>> Until now, when we connect gdb to the QEMU gdb-server, the
>> single-step mode is not managed.
>>
>> This patch adds this, only for kvm-pr:
>>
>> If KVM_GUESTDBG_SINGLESTEP is set, we enable single-step trace bit in the
>> MSR (MSR_SE) just before the __kvmppc_vcpu_run(), and disable it just after.
>> In kvmppc_handle_exit_pr, instead of routing the interrupt to
>> the guest, we return to host, with KVM_EXIT_DEBUG reason.
>>
>> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
>> ---
>>  arch/powerpc/kvm/book3s_pr.c | 31 +++++++++++++++++++++++++++++--
>>  1 file changed, 29 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
>> index 95bceca..e6896f4 100644
>> --- a/arch/powerpc/kvm/book3s_pr.c
>> +++ b/arch/powerpc/kvm/book3s_pr.c
>> @@ -882,6 +882,24 @@ void kvmppc_set_fscr(struct kvm_vcpu *vcpu, u64 fscr)
>>  }
>>  #endif
>>  
>> +static void kvmppc_setup_debug(struct kvm_vcpu *vcpu)
>> +{
>> +	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
>> +		u64 msr = kvmppc_get_msr(vcpu);
>> +
>> +		kvmppc_set_msr(vcpu, msr | MSR_SE);
>> +	}
>> +}
>> +
>> +static void kvmppc_clear_debug(struct kvm_vcpu *vcpu)
>> +{
>> +	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
>> +		u64 msr = kvmppc_get_msr(vcpu);
>> +
>> +		kvmppc_set_msr(vcpu, msr & ~MSR_SE);
>> +	}
>> +}
>> +
>>  int kvmppc_handle_exit_pr(struct kvm_run *run, struct kvm_vcpu *vcpu,
>>  			  unsigned int exit_nr)
>>  {
>> @@ -1208,8 +1226,13 @@ program_interrupt:
>>  #endif
>>  	case BOOK3S_INTERRUPT_MACHINE_CHECK:
>>  	case BOOK3S_INTERRUPT_TRACE:
>> -		kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
>> -		r = RESUME_GUEST;
>> +		if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
>> +			run->exit_reason = KVM_EXIT_DEBUG;
>> +			r = RESUME_HOST;
>> +		} else {
>> +			kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
>> +			r = RESUME_GUEST;
>> +		}
> 
> Should the new code rather be limited to the BOOK3S_INTERRUPT_TRACE case
> only? I mean, this way, you never can deliver a machine check interrupt
> to the guest if singlestep debugging is enabled on the host, can you?

You're right but it adds complexity and it would be only useful to
single-step the single-step mode of the guest.

It's hard to imagine a developer single-stepping the guest kernel while
he is single-stepping a user application in the guest.

It's why I have completely by-passed this case.

Thanks,
Laurent

WARNING: multiple messages have this Message-ID (diff)
From: Laurent Vivier <lvivier@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
	kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
Cc: Gleb Natapov <gleb@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Alexander Graf <agraf@suse.com>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
	dgibson@redhat.com
Subject: Re: [PATCH] kvm-pr: manage single-step mode
Date: Fri, 8 Apr 2016 08:58:35 +0200	[thread overview]
Message-ID: <5707569B.1000704@redhat.com> (raw)
In-Reply-To: <57074E45.4040204@redhat.com>



On 08/04/2016 08:23, Thomas Huth wrote:
> On 22.03.2016 15:53, Laurent Vivier wrote:
>> Until now, when we connect gdb to the QEMU gdb-server, the
>> single-step mode is not managed.
>>
>> This patch adds this, only for kvm-pr:
>>
>> If KVM_GUESTDBG_SINGLESTEP is set, we enable single-step trace bit in the
>> MSR (MSR_SE) just before the __kvmppc_vcpu_run(), and disable it just after.
>> In kvmppc_handle_exit_pr, instead of routing the interrupt to
>> the guest, we return to host, with KVM_EXIT_DEBUG reason.
>>
>> Signed-off-by: Laurent Vivier <lvivier@redhat.com>
>> ---
>>  arch/powerpc/kvm/book3s_pr.c | 31 +++++++++++++++++++++++++++++--
>>  1 file changed, 29 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
>> index 95bceca..e6896f4 100644
>> --- a/arch/powerpc/kvm/book3s_pr.c
>> +++ b/arch/powerpc/kvm/book3s_pr.c
>> @@ -882,6 +882,24 @@ void kvmppc_set_fscr(struct kvm_vcpu *vcpu, u64 fscr)
>>  }
>>  #endif
>>  
>> +static void kvmppc_setup_debug(struct kvm_vcpu *vcpu)
>> +{
>> +	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
>> +		u64 msr = kvmppc_get_msr(vcpu);
>> +
>> +		kvmppc_set_msr(vcpu, msr | MSR_SE);
>> +	}
>> +}
>> +
>> +static void kvmppc_clear_debug(struct kvm_vcpu *vcpu)
>> +{
>> +	if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
>> +		u64 msr = kvmppc_get_msr(vcpu);
>> +
>> +		kvmppc_set_msr(vcpu, msr & ~MSR_SE);
>> +	}
>> +}
>> +
>>  int kvmppc_handle_exit_pr(struct kvm_run *run, struct kvm_vcpu *vcpu,
>>  			  unsigned int exit_nr)
>>  {
>> @@ -1208,8 +1226,13 @@ program_interrupt:
>>  #endif
>>  	case BOOK3S_INTERRUPT_MACHINE_CHECK:
>>  	case BOOK3S_INTERRUPT_TRACE:
>> -		kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
>> -		r = RESUME_GUEST;
>> +		if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) {
>> +			run->exit_reason = KVM_EXIT_DEBUG;
>> +			r = RESUME_HOST;
>> +		} else {
>> +			kvmppc_book3s_queue_irqprio(vcpu, exit_nr);
>> +			r = RESUME_GUEST;
>> +		}
> 
> Should the new code rather be limited to the BOOK3S_INTERRUPT_TRACE case
> only? I mean, this way, you never can deliver a machine check interrupt
> to the guest if singlestep debugging is enabled on the host, can you?

You're right but it adds complexity and it would be only useful to
single-step the single-step mode of the guest.

It's hard to imagine a developer single-stepping the guest kernel while
he is single-stepping a user application in the guest.

It's why I have completely by-passed this case.

Thanks,
Laurent

  reply	other threads:[~2016-04-08  6:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-22 14:53 [PATCH] kvm-pr: manage single-step mode Laurent Vivier
2016-03-22 14:53 ` Laurent Vivier
2016-04-07 11:32 ` Laurent Vivier
2016-04-07 11:32   ` Laurent Vivier
2016-04-08  6:23 ` Thomas Huth
2016-04-08  6:23   ` Thomas Huth
2016-04-08  6:58   ` Laurent Vivier [this message]
2016-04-08  6:58     ` Laurent Vivier
2016-04-08  7:44     ` Thomas Huth
2016-04-08  7:44       ` Thomas Huth
2016-04-08  8:03       ` Laurent Vivier
2016-04-08  8:03         ` Laurent Vivier

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=5707569B.1000704@redhat.com \
    --to=lvivier@redhat.com \
    --cc=agraf@suse.com \
    --cc=benh@kernel.crashing.org \
    --cc=dgibson@redhat.com \
    --cc=gleb@kernel.org \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=pbonzini@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is 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.