All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabiano Rosas <farosas@linux.ibm.com>
To: kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: Book3S PR: fix software breakpoints
Date: Fri, 14 Jun 2019 22:14:31 +0000	[thread overview]
Message-ID: <871rzv4xx4.fsf@linux.ibm.com> (raw)
In-Reply-To: <20190614185745.6863-1-mark.cave-ayland@ilande.co.uk>

Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:

> QEMU's kvm_handle_debug() function identifies software breakpoints by checking
> for a value of 0 in kvm_debug_exit_arch's status field. Since this field isn't

LGTM, but let me start a discussion:

In arch/powerpc/include/uapi/asm/kvm.h I see the following:


/*
 * Defines for h/w breakpoint, watchpoint (read, write or both) and
 * software breakpoint.
 * These are used as "type" in KVM_SET_GUEST_DEBUG ioctl and "status"
 * for KVM_DEBUG_EXIT.
 */
#define KVMPPC_DEBUG_NONE		0x0
#define KVMPPC_DEBUG_BREAKPOINT		(1UL << 1)
#define KVMPPC_DEBUG_WATCH_WRITE	(1UL << 2)
#define KVMPPC_DEBUG_WATCH_READ		(1UL << 3)


this seems to be biased towards the BookE implementation which uses
KVMPPC_DEBUG_BREAKPOINT to indicate a "hardware breakpoint" (i.e. Instruction
Address Compare - ISA v2 Book III-E, section 10.4.1), and then
KVMPPC_DEBUG_NONE ends up implicitly meaning "software breakpoint" for
Book3s PR/HV.

> explicitly set to 0 when the software breakpoint instruction is detected, any
> previous non-zero value present causes a hang in QEMU as it tries to process
> the breakpoint instruction incorrectly as a hardware breakpoint.

What QEMU does (again biased towards BookE) is to check the 'status'
field and treat both h/w breakpoints and watchpoints as hardware
breakpoints (which is correct in a sense) and then proceed to look for
s/w breakpoints:

    if (arch_info->status) {
        return kvm_handle_hw_breakpoint(cs, arch_info);
    }

    if (kvm_find_sw_breakpoint(cs, arch_info->address)) {
        return kvm_handle_sw_breakpoint(cs, arch_info->address);
    }

So I wonder if it would not be beneficial for future developers if we
drew the line and made a clear distinction between:

 software breakpoints - triggered by a KVMPPC_INST_SW_BREAKPOINT execution
 hardware breakpoints - triggered by some register match

Maybe by turning the first two defines into:

#define KVMPPC_DEBUG_SW_BREAKPOINT 0x0
#define KVMPPC_DEBUG_HW_BREAKPOINT (1UL << 1)

> Ensure that the kvm_debug_exit_arch status field is set to 0 when the software
> breakpoint instruction is detected (similar to the existing logic in booke.c
> and e500_emulate.c) to restore software breakpoint functionality under Book3S
> PR.
>
> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> ---

Anyway, the proposed patch fixes the issue.

Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com>

>  arch/powerpc/kvm/emulate.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> index bb4d09c1ad56..6fca38ca791f 100644
> --- a/arch/powerpc/kvm/emulate.c
> +++ b/arch/powerpc/kvm/emulate.c
> @@ -271,6 +271,7 @@ int kvmppc_emulate_instruction(struct kvm_run *run, struct kvm_vcpu *vcpu)
>  		 */
>  		if (inst = KVMPPC_INST_SW_BREAKPOINT) {
>  			run->exit_reason = KVM_EXIT_DEBUG;
> +			run->debug.arch.status = 0;
>  			run->debug.arch.address = kvmppc_get_pc(vcpu);
>  			emulated = EMULATE_EXIT_USER;
>  			advance = 0;

  reply	other threads:[~2019-06-14 22:14 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-14 18:57 [PATCH] KVM: PPC: Book3S PR: fix software breakpoints Mark Cave-Ayland
2019-06-14 22:14 ` Fabiano Rosas [this message]
2019-06-16 15:33 ` Mark Cave-Ayland
2019-06-17  6:32 ` Paul Mackerras

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=871rzv4xx4.fsf@linux.ibm.com \
    --to=farosas@linux.ibm.com \
    --cc=kvm-ppc@vger.kernel.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.