All of lore.kernel.org
 help / color / mirror / Atom feed
* x86: Hardware breakpoints are not always triggered
@ 2016-01-28  8:31 Andrey Wagin
  2016-01-28 11:01 ` Jan Kiszka
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Andrey Wagin @ 2016-01-28  8:31 UTC (permalink / raw)
  To: LKML, Andy Lutomirski, Cyrill Gorcunov, Oleg Nesterov, criu, kvm

[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]

Hi,

We use hardware breakpoints in CRIU and we found that sometimes we set
a break-point, but a process doesn't stop on it.

I write a small reproducer for this bug. It create two processes,
where a parent process traces a child. The parent process sets a
break-point and each time when the child stop on it, the parent sets
the variable "xxx" to A in a child process. The child runs an infinite
loop, where it check the variable "xxx" and sets it to B. If a child
process finds that xxx is equal to B, it exits with a non-zero code,
what means that a break-point was not triggered. The source code is
attached.

The reproducer uses a different break-point address if it is executed
with arguments than when it executed without arguments.

Then I made a few experiments. The bug is triggered, if we execute
this program a few times in a KVM virtual machine.

[root@fc22-vm ptrace]# ( while :; do ./ptrace_breakpoint > /dev/null
|| { echo "FAIL - $?"; break; }; done ) &
[3] 4088
[root@fc22-vm ptrace]# ( while :; do ./ptrace_breakpoint > /dev/null
|| { echo "FAIL - $?"; break; }; done ) &
[4] 4091
[root@fc22-vm ptrace]# ( while :; do ./ptrace_breakpoint 1 2 >
/dev/null || { echo "FAIL - $?"; break; }; done ) &
[5] 4094
[root@fc22-vm ptrace]# ( while :; do ./ptrace_breakpoint 1 2 >
/dev/null || { echo "FAIL - $?"; break; }; done ) &
[6] 4097
[8] 4103
[root@fc22-vm ptrace]# 0087: exit - 5
0131: exited, status=1
0126: wait: No child processes
FAIL - 3

I tried to execute the reproducer on the host (where kvm VM-s are
running), but the bug was not triggered during one hour.

When I executed the reproducer in VM without stopping processes on the
host, I found that a bug is triggered much faster in this case.

[root@fc22-vm ptrace]# ./ptrace_breakpoint 1
....
stop 24675
cont
child2 1
stop 24676
cont
child2 1
child2 5
0088: exit - 5
stop 24677
0132: exited, status=1
cont
0127: wait: No child processes

I know that this bug can be reproduced starting with the 4.2 kernel. I
haven't test older versions of the kernel.

I tried to print drX registers after a break-point. Looks like they
are set correctly.

Maybe someone has any ideas where a problem is or how it can be investigated.

Here is a criu issue for this problem:
https://github.com/xemul/criu/issues/107

Thanks,
Andrew

[-- Attachment #2: ptrace_breakpoint.c --]
[-- Type: text/x-csrc, Size: 3521 bytes --]

#define _GNU_SOURCE         /* See feature_test_macros(7) */
#include <sys/syscall.h>   /* For SYS_xxx definitions */

#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <errno.h>
#include <sys/user.h>
#include <asm/debugreg.h>
#include <string.h>

/* Copied from the gdb header gdb/nat/x86-dregs.h */

/* Debug registers' indices.  */
#define DR_FIRSTADDR 0
#define DR_LASTADDR  3
#define DR_NADDR     4  /* The number of debug address registers.  */
#define DR_STATUS    6  /* Index of debug status register (DR6).  */
#define DR_CONTROL   7  /* Index of debug control register (DR7).  */

#define DR_LOCAL_ENABLE_SHIFT   0 /* Extra shift to the local enable bit.  */
#define DR_GLOBAL_ENABLE_SHIFT  1 /* Extra shift to the global enable bit.  */
#define DR_ENABLE_SIZE          2 /* Two enable bits per debug register.  */

/* Locally enable the break/watchpoint in the I'th debug register.  */
#define X86_DR_LOCAL_ENABLE(i) (1 << (DR_LOCAL_ENABLE_SHIFT + DR_ENABLE_SIZE * (i)))


# define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
#define pr_perror(fmt, ...)                                             \
		fprintf(stderr, "%04d: " fmt ": %s\n", __LINE__, ##__VA_ARGS__, strerror(errno))
#define pr_err(fmt, ...)                                             \
		fprintf(stderr, "%04d: " fmt "\n", __LINE__, ##__VA_ARGS__)

int ptrace_set_breakpoint(pid_t pid, void *addr)
{
        int ret;

        /* Set a breakpoint */
        if (ptrace(PTRACE_POKEUSER, pid,
                        offsetof(struct user, u_debugreg[DR_FIRSTADDR]),
                        addr)) {
                pr_perror("Unable to setup a breakpoint into %d", pid);
                return -1;
        }

        /* Enable the breakpoint */
        if (ptrace(PTRACE_POKEUSER, pid,
                        offsetof(struct user, u_debugreg[DR_CONTROL]),
                        X86_DR_LOCAL_ENABLE(DR_FIRSTADDR))) {
                pr_perror("Unable to enable the breakpoint for %d", pid);
                return -1;
        }

        ret = ptrace(PTRACE_CONT, pid, NULL, NULL);
        if (ret) {
                pr_perror("Unable to restart the  stopped tracee process %d", pid);
                return -1;
        }

        return 1;
}

static long xxx = -1;
int child()
{
	printf("child %d\n", xxx);
	syscall(__NR_getppid);
	if (xxx == 5) {
		pr_err("exit - %d", xxx);
		exit(1);
	}
	if (xxx > 0)
		xxx = 5;
	return 0;
}

int child2()
{
	printf("child2 %d\n", xxx);
	syscall(__NR_getppid);
	if (xxx == 5) {
		pr_err("exit - %d", xxx);
		exit(1);
	}
	if (xxx > 0)
		xxx = 5;
	return 0;
}

int main(int argc, char **argv)
{
	pid_t pid;
	int status, i = 0;
	int (*addr)();

	if (argc > 1)
		addr = child2;
	else
		addr = child;

	pid = fork();
	if (pid == 0) {
		while (1)
			addr();
	}

	if (ptrace(PTRACE_ATTACH, pid, NULL, NULL)) {
		pr_perror("ptrace");
		return 1;
	}
	if (waitpid(pid, &status, 0) == -1) {
		pr_perror("waitpid");
		return 1;
	}

	if (ptrace_set_breakpoint(pid, addr) != 1)
		return 2;

	while (1) {
		if (waitpid(pid, &status, 0) != pid) {
			pr_perror("wait");
			return 3;
		}
		printf("stop %d\n", i++);
		if (WIFEXITED(status)) {
			pr_err("exited, status=%d", WEXITSTATUS(status));
		} else if (WIFSIGNALED(status)) {
			pr_err("killed by signal %d", WTERMSIG(status));
		}
		ptrace(PTRACE_POKEDATA, pid, &xxx, 1);
		printf("cont\n");
		ptrace(PTRACE_CONT, pid, NULL, NULL);
	}


	return 0;
}

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: x86: Hardware breakpoints are not always triggered
  2016-01-28  8:31 x86: Hardware breakpoints are not always triggered Andrey Wagin
@ 2016-01-28 11:01 ` Jan Kiszka
  2016-01-28 20:53 ` Oleg Nesterov
  2016-01-28 21:33 ` Paolo Bonzini
  2 siblings, 0 replies; 12+ messages in thread
From: Jan Kiszka @ 2016-01-28 11:01 UTC (permalink / raw)
  To: Andrey Wagin, LKML, Andy Lutomirski, Cyrill Gorcunov,
	Oleg Nesterov, criu, kvm

On 2016-01-28 09:31, Andrey Wagin wrote:
> Hi,
> 
> We use hardware breakpoints in CRIU and we found that sometimes we set
> a break-point, but a process doesn't stop on it.
> 
> I write a small reproducer for this bug. It create two processes,
> where a parent process traces a child. The parent process sets a
> break-point and each time when the child stop on it, the parent sets
> the variable "xxx" to A in a child process. The child runs an infinite
> loop, where it check the variable "xxx" and sets it to B. If a child
> process finds that xxx is equal to B, it exits with a non-zero code,
> what means that a break-point was not triggered. The source code is
> attached.
> 
> The reproducer uses a different break-point address if it is executed
> with arguments than when it executed without arguments.
> 
> Then I made a few experiments. The bug is triggered, if we execute
> this program a few times in a KVM virtual machine.
> 
> [root@fc22-vm ptrace]# ( while :; do ./ptrace_breakpoint > /dev/null
> || { echo "FAIL - $?"; break; }; done ) &
> [3] 4088
> [root@fc22-vm ptrace]# ( while :; do ./ptrace_breakpoint > /dev/null
> || { echo "FAIL - $?"; break; }; done ) &
> [4] 4091
> [root@fc22-vm ptrace]# ( while :; do ./ptrace_breakpoint 1 2 >
> /dev/null || { echo "FAIL - $?"; break; }; done ) &
> [5] 4094
> [root@fc22-vm ptrace]# ( while :; do ./ptrace_breakpoint 1 2 >
> /dev/null || { echo "FAIL - $?"; break; }; done ) &
> [6] 4097
> [8] 4103
> [root@fc22-vm ptrace]# 0087: exit - 5
> 0131: exited, status=1
> 0126: wait: No child processes
> FAIL - 3
> 
> I tried to execute the reproducer on the host (where kvm VM-s are
> running), but the bug was not triggered during one hour.
> 
> When I executed the reproducer in VM without stopping processes on the
> host, I found that a bug is triggered much faster in this case.
> 
> [root@fc22-vm ptrace]# ./ptrace_breakpoint 1
> ....
> stop 24675
> cont
> child2 1
> stop 24676
> cont
> child2 1
> child2 5
> 0088: exit - 5
> stop 24677
> 0132: exited, status=1
> cont
> 0127: wait: No child processes
> 
> I know that this bug can be reproduced starting with the 4.2 kernel. I
> haven't test older versions of the kernel.
> 
> I tried to print drX registers after a break-point. Looks like they
> are set correctly.
> 
> Maybe someone has any ideas where a problem is or how it can be investigated.
> 
> Here is a criu issue for this problem:
> https://github.com/xemul/criu/issues/107
> 
> Thanks,
> Andrew
> 

You could try to trace the failure on the host and compare events with
good cases:

http://www.linux-kvm.org/page/Tracing

It would interesting, e.g., if there is a #DB related vmexit but then no
event injection back into the guest when it should be.

However, tracing will become tricky if multiple reproducer processes run
on the guest side. Then you need some additional guest-side
instrumentation to correlate host events with guest processes. On x86, I
often use cpuid with bogus/made-up parameters - they will hit the
host-side trace.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: x86: Hardware breakpoints are not always triggered
  2016-01-28  8:31 x86: Hardware breakpoints are not always triggered Andrey Wagin
  2016-01-28 11:01 ` Jan Kiszka
@ 2016-01-28 20:53 ` Oleg Nesterov
  2016-01-28 21:29   ` Paolo Bonzini
  2016-01-28 22:01   ` Oleg Nesterov
  2016-01-28 21:33 ` Paolo Bonzini
  2 siblings, 2 replies; 12+ messages in thread
From: Oleg Nesterov @ 2016-01-28 20:53 UTC (permalink / raw)
  To: Andrey Wagin; +Cc: LKML, Andy Lutomirski, Cyrill Gorcunov, criu, kvm

On 01/28, Andrey Wagin wrote:
>
> We use hardware breakpoints in CRIU and we found that sometimes we set
> a break-point, but a process doesn't stop on it.

reproduced, and this certainly looks like kvm bug to me.

> The reproducer uses a different break-point address if it is executed
> with arguments than when it executed without arguments.

IOW, multiple processes running in parallel use the same debug register db0
but different address. And it seems that set_debugreg(address, 0) sometime
doesn't work in the guest kernel.

I think I verified the following:

	- debug registers look always correct as it seen by the guest.
	  I used get_debugreg() to dump them after the task misses bp.

	- do_debug() was not called in this case.

	- finally, it seems that the host has the wrong value in db0
	  set by another process.

	  I modified your test-case so that child2() calls child() when
	  it detects the missed bp, and this does trigger do_debug/etc
	  while it should not.

Oleg.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: x86: Hardware breakpoints are not always triggered
  2016-01-28 20:53 ` Oleg Nesterov
@ 2016-01-28 21:29   ` Paolo Bonzini
  2016-01-28 22:01   ` Oleg Nesterov
  1 sibling, 0 replies; 12+ messages in thread
From: Paolo Bonzini @ 2016-01-28 21:29 UTC (permalink / raw)
  To: Oleg Nesterov, Andrey Wagin
  Cc: LKML, Andy Lutomirski, Cyrill Gorcunov, criu, kvm



On 28/01/2016 21:53, Oleg Nesterov wrote:
> > We use hardware breakpoints in CRIU and we found that sometimes we set
> > a break-point, but a process doesn't stop on it.
> 
> reproduced, and this certainly looks like kvm bug to me.

Yes, in all likelihood.  Thanks, I'll reproduce and look for a fix.

Paolo

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: x86: Hardware breakpoints are not always triggered
  2016-01-28  8:31 x86: Hardware breakpoints are not always triggered Andrey Wagin
  2016-01-28 11:01 ` Jan Kiszka
  2016-01-28 20:53 ` Oleg Nesterov
@ 2016-01-28 21:33 ` Paolo Bonzini
  2016-01-28 22:42   ` Andrey Wagin
  2 siblings, 1 reply; 12+ messages in thread
From: Paolo Bonzini @ 2016-01-28 21:33 UTC (permalink / raw)
  To: Andrey Wagin, LKML, Andy Lutomirski, Cyrill Gorcunov,
	Oleg Nesterov, criu, kvm



On 28/01/2016 09:31, Andrey Wagin wrote:
> I tried to print drX registers after a break-point. Looks like they
> are set correctly.

Can you try this KVM patch?

diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index c13a64b7d789..32bae1c70a50 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1612,6 +1612,7 @@ static void svm_sync_dirty_debug_regs(struct kvm_vcpu *vcpu)
 	vcpu->arch.dr7 = svm->vmcb->save.dr7;
 
 	vcpu->arch.switch_db_regs &= ~KVM_DEBUGREG_WONT_EXIT;
+	vcpu->arch.switch_db_regs |= KVM_DEBUGREG_RELOAD;
 	set_dr_intercepts(svm);
 }
 
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index e2951b6edbbc..505a4663b9f4 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -5659,6 +5659,7 @@ static void vmx_sync_dirty_debug_regs(struct kvm_vcpu *vcpu)
 	vcpu->arch.dr7 = vmcs_readl(GUEST_DR7);
 
 	vcpu->arch.switch_db_regs &= ~KVM_DEBUGREG_WONT_EXIT;
+	vcpu->arch.switch_db_regs |= KVM_DEBUGREG_RELOAD;
 
 	cpu_based_vm_exec_control = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL);
 	cpu_based_vm_exec_control |= CPU_BASED_MOV_DR_EXITING;

Paolo

^ permalink raw reply related	[flat|nested] 12+ messages in thread

* Re: x86: Hardware breakpoints are not always triggered
  2016-01-28 20:53 ` Oleg Nesterov
  2016-01-28 21:29   ` Paolo Bonzini
@ 2016-01-28 22:01   ` Oleg Nesterov
  1 sibling, 0 replies; 12+ messages in thread
From: Oleg Nesterov @ 2016-01-28 22:01 UTC (permalink / raw)
  To: Andrey Wagin; +Cc: LKML, Andy Lutomirski, Cyrill Gorcunov, criu, kvm

On 01/28, Oleg Nesterov wrote:
>
> On 01/28, Andrey Wagin wrote:
> >
> > We use hardware breakpoints in CRIU and we found that sometimes we set
> > a break-point, but a process doesn't stop on it.
>
> reproduced, and this certainly looks like kvm bug to me.
>
> > The reproducer uses a different break-point address if it is executed
> > with arguments than when it executed without arguments.
>
> IOW, multiple processes running in parallel use the same debug register db0
> but different address. And it seems that set_debugreg(address, 0) sometime
> doesn't work in the guest kernel.
>
> I think I verified the following:
>
> 	- debug registers look always correct as it seen by the guest.
> 	  I used get_debugreg() to dump them after the task misses bp.
>
> 	- do_debug() was not called in this case.
>
> 	- finally, it seems that the host has the wrong value in db0
> 	  set by another process.
>
> 	  I modified your test-case so that child2() calls child() when
> 	  it detects the missed bp, and this does trigger do_debug/etc
> 	  while it should not.

See another test-case below.

I am running "./bp 0 1" on the host and "./bp 14 15" under QEMU, this immediately
leads to

	ERR!! hit wrong bp 0 != 14
	ERR!! hit wrong bp 0 != 14
	ERR!! hit wrong bp 0 != 14
	ERR!! hit wrong bp 1 != 14
	...

Oleg.
-------------------------------------------------------------------------------

#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <sys/user.h>
#include <asm/debugreg.h>
#include <assert.h>

#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)

unsigned long encode_dr7(int drnum, int enable, unsigned int type, unsigned int len)
{
	unsigned long dr7;

	dr7 = ((len | type) & 0xf)
		<< (DR_CONTROL_SHIFT + drnum * DR_CONTROL_SIZE);
	if (enable)
		dr7 |= (DR_GLOBAL_ENABLE << (drnum * DR_ENABLE_SIZE));

	return dr7;
}

int write_dr(int pid, int dr, unsigned long val)
{
	return ptrace(PTRACE_POKEUSER, pid,
			offsetof (struct user, u_debugreg[dr]),
			val);
}

void set_bp(pid_t pid, void *addr)
{
	unsigned long dr7;
	assert(write_dr(pid, 0, (long)addr) == 0);
	dr7 = encode_dr7(0, 1, DR_RW_EXECUTE, DR_LEN_1);
	assert(write_dr(pid, 7, dr7) == 0);
}

void *get_rip(int pid)
{
	return (void*)ptrace(PTRACE_PEEKUSER, pid,
			offsetof(struct user, regs.rip), 0);
}

void test(int nr)
{
	void *bp_addr = &&label + nr, *bp_hit;
	int pid;

	printf("test bp %d\n", nr);
	assert(nr < 16); // see 16 asm nops below

	pid = fork();
	if (!pid) {
		assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
		kill(getpid(), SIGSTOP);
		for (;;) {
			label: asm (
				"nop; nop; nop; nop;"
				"nop; nop; nop; nop;"
				"nop; nop; nop; nop;"
				"nop; nop; nop; nop;"
			);
		}
	}

	assert(pid == wait(NULL));
	set_bp(pid, bp_addr);

	for (;;) {
		assert(ptrace(PTRACE_CONT, pid, 0, 0) == 0);
		assert(pid == wait(NULL));

		bp_hit = get_rip(pid);
		if (bp_hit != bp_addr)
			fprintf(stderr, "ERR!! hit wrong bp %ld != %d\n",
				bp_hit - &&label, nr);
	}
}

int main(int argc, const char *argv[])
{
	while (--argc) {
		int nr = atoi(*++argv);
		if (!fork())
			test(nr);
	}

	while (wait(NULL) > 0)
		;
	return 0;
}

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: x86: Hardware breakpoints are not always triggered
  2016-01-28 21:33 ` Paolo Bonzini
@ 2016-01-28 22:42   ` Andrey Wagin
  2016-01-29 22:21     ` [CRIU] " Andrew Vagin
  0 siblings, 1 reply; 12+ messages in thread
From: Andrey Wagin @ 2016-01-28 22:42 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: LKML, Andy Lutomirski, Cyrill Gorcunov, Oleg Nesterov, criu, kvm

On Thu, Jan 28, 2016 at 10:33:28PM +0100, Paolo Bonzini wrote:
> 
> 
> On 28/01/2016 09:31, Andrey Wagin wrote:
> > I tried to print drX registers after a break-point. Looks like they
> > are set correctly.
> 
> Can you try this KVM patch?

Looks like it fixes a case when reproducers are running only in VM.

If I execute the reproducer a few times on the host and then execute it
in VM, it exits very fast.

Thanks,
Andrew

> 
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index c13a64b7d789..32bae1c70a50 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -1612,6 +1612,7 @@ static void svm_sync_dirty_debug_regs(struct kvm_vcpu *vcpu)
>  	vcpu->arch.dr7 = svm->vmcb->save.dr7;
>  
>  	vcpu->arch.switch_db_regs &= ~KVM_DEBUGREG_WONT_EXIT;
> +	vcpu->arch.switch_db_regs |= KVM_DEBUGREG_RELOAD;
>  	set_dr_intercepts(svm);
>  }
>  
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index e2951b6edbbc..505a4663b9f4 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -5659,6 +5659,7 @@ static void vmx_sync_dirty_debug_regs(struct kvm_vcpu *vcpu)
>  	vcpu->arch.dr7 = vmcs_readl(GUEST_DR7);
>  
>  	vcpu->arch.switch_db_regs &= ~KVM_DEBUGREG_WONT_EXIT;
> +	vcpu->arch.switch_db_regs |= KVM_DEBUGREG_RELOAD;
>  
>  	cpu_based_vm_exec_control = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL);
>  	cpu_based_vm_exec_control |= CPU_BASED_MOV_DR_EXITING;
> 
> Paolo

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [CRIU] x86: Hardware breakpoints are not always triggered
  2016-01-28 22:42   ` Andrey Wagin
@ 2016-01-29 22:21     ` Andrew Vagin
  2016-01-31 11:01       ` Paolo Bonzini
  0 siblings, 1 reply; 12+ messages in thread
From: Andrew Vagin @ 2016-01-29 22:21 UTC (permalink / raw)
  To: Andrey Wagin
  Cc: Paolo Bonzini, kvm, Oleg Nesterov, LKML, criu, Cyrill Gorcunov

On Thu, Jan 28, 2016 at 02:42:25PM -0800, Andrey Wagin wrote:
> On Thu, Jan 28, 2016 at 10:33:28PM +0100, Paolo Bonzini wrote:
> > 
> > 
> > On 28/01/2016 09:31, Andrey Wagin wrote:
> > > I tried to print drX registers after a break-point. Looks like they
> > > are set correctly.
> > 
> > Can you try this KVM patch?
> 
> Looks like it fixes a case when reproducers are running only in VM.

Actually Oleg's reproducer detects the bug with this patch when they are
rinning only in VM.

> 
> If I execute the reproducer a few times on the host and then execute it
> in VM, it exits very fast.
> 
> Thanks,
> Andrew
> 
> > 
> > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> > index c13a64b7d789..32bae1c70a50 100644
> > --- a/arch/x86/kvm/svm.c
> > +++ b/arch/x86/kvm/svm.c
> > @@ -1612,6 +1612,7 @@ static void svm_sync_dirty_debug_regs(struct kvm_vcpu *vcpu)
> >  	vcpu->arch.dr7 = svm->vmcb->save.dr7;
> >  
> >  	vcpu->arch.switch_db_regs &= ~KVM_DEBUGREG_WONT_EXIT;
> > +	vcpu->arch.switch_db_regs |= KVM_DEBUGREG_RELOAD;
> >  	set_dr_intercepts(svm);
> >  }
> >  
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > index e2951b6edbbc..505a4663b9f4 100644
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -5659,6 +5659,7 @@ static void vmx_sync_dirty_debug_regs(struct kvm_vcpu *vcpu)
> >  	vcpu->arch.dr7 = vmcs_readl(GUEST_DR7);
> >  
> >  	vcpu->arch.switch_db_regs &= ~KVM_DEBUGREG_WONT_EXIT;
> > +	vcpu->arch.switch_db_regs |= KVM_DEBUGREG_RELOAD;
> >  
> >  	cpu_based_vm_exec_control = vmcs_read32(CPU_BASED_VM_EXEC_CONTROL);
> >  	cpu_based_vm_exec_control |= CPU_BASED_MOV_DR_EXITING;
> > 
> > Paolo
> _______________________________________________
> CRIU mailing list
> CRIU@openvz.org
> https://lists.openvz.org/mailman/listinfo/criu

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [CRIU] x86: Hardware breakpoints are not always triggered
  2016-01-29 22:21     ` [CRIU] " Andrew Vagin
@ 2016-01-31 11:01       ` Paolo Bonzini
  2016-02-03 18:18         ` Nadav Amit
  0 siblings, 1 reply; 12+ messages in thread
From: Paolo Bonzini @ 2016-01-31 11:01 UTC (permalink / raw)
  To: Andrew Vagin, Andrey Wagin
  Cc: kvm, Oleg Nesterov, LKML, criu, Cyrill Gorcunov



On 29/01/2016 23:21, Andrew Vagin wrote:
> On Thu, Jan 28, 2016 at 02:42:25PM -0800, Andrey Wagin wrote:
>> On Thu, Jan 28, 2016 at 10:33:28PM +0100, Paolo Bonzini wrote:
>>>
>>>
>>> On 28/01/2016 09:31, Andrey Wagin wrote:
>>>> I tried to print drX registers after a break-point. Looks like they
>>>> are set correctly.
>>>
>>> Can you try this KVM patch?
>>
>> Looks like it fixes a case when reproducers are running only in VM.
> 
> Actually Oleg's reproducer detects the bug with this patch when they are
> rinning only in VM.

That's actually a good thing, because the patch was a long shot and I
had no clue _why_ it would have fixed the bug.  Oleg's reproducer
spanning host and a VM actually gives me an idea of what is going on,
I'll try to reproduce this week.

Paolo

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [CRIU] x86: Hardware breakpoints are not always triggered
  2016-01-31 11:01       ` Paolo Bonzini
@ 2016-02-03 18:18         ` Nadav Amit
  2016-02-03 23:32           ` Nadav Amit
  0 siblings, 1 reply; 12+ messages in thread
From: Nadav Amit @ 2016-02-03 18:18 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Andrew Vagin, Andrey Wagin, kvm, Oleg Nesterov, LKML, criu,
	Cyrill Gorcunov

I think the problem lies here:

        /*
         * If the guest has used debug registers, at least dr7
         * will be disabled while returning to the host.
         * If we don't have active breakpoints in the host, we don't
         * care about the messed up debug address registers. But if
         * we have some of them active, restore the old state.
         */
        if (hw_breakpoint_active()) {
                hw_breakpoint_restore();
        }

First we need to reload the DRs after we do hw_breakpoint_restore(), no?
	vcpu->arch.switch_db_regs |= KVM_DEBUGREG_RELOAD;

Second, I am unsure whether hw_breakpoint_active() is the correct condition.

In my defense note that my tests did not his this case since I set affinity
of the VCPUs to physical cores, and prevented other processes from running.

Regards,
Nadav

Paolo Bonzini <pbonzini@redhat.com> wrote:

> 
> 
> On 29/01/2016 23:21, Andrew Vagin wrote:
>> On Thu, Jan 28, 2016 at 02:42:25PM -0800, Andrey Wagin wrote:
>>> On Thu, Jan 28, 2016 at 10:33:28PM +0100, Paolo Bonzini wrote:
>>>> On 28/01/2016 09:31, Andrey Wagin wrote:
>>>>> I tried to print drX registers after a break-point. Looks like they
>>>>> are set correctly.
>>>> 
>>>> Can you try this KVM patch?
>>> 
>>> Looks like it fixes a case when reproducers are running only in VM.
>> 
>> Actually Oleg's reproducer detects the bug with this patch when they are
>> rinning only in VM.
> 
> That's actually a good thing, because the patch was a long shot and I
> had no clue _why_ it would have fixed the bug.  Oleg's reproducer
> spanning host and a VM actually gives me an idea of what is going on,
> I'll try to reproduce this week.
> 
> Paolo
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [CRIU] x86: Hardware breakpoints are not always triggered
  2016-02-03 18:18         ` Nadav Amit
@ 2016-02-03 23:32           ` Nadav Amit
  2016-02-04 11:28             ` Paolo Bonzini
  0 siblings, 1 reply; 12+ messages in thread
From: Nadav Amit @ 2016-02-03 23:32 UTC (permalink / raw)
  To: Paolo Bonzini
  Cc: Andrew Vagin, Andrey Wagin, kvm, Oleg Nesterov, LKML, criu,
	Cyrill Gorcunov

Sorry for spamming. The correct fix appears to reload the DRs (set
KVM_DEBUGREG_RELOAD) in kvm_arch_vcpu_load .

(for me it works)

Regards,
Nadav

 

Nadav Amit <nadav.amit@gmail.com> wrote:

> I think the problem lies here:
> 
>        /*
>         * If the guest has used debug registers, at least dr7
>         * will be disabled while returning to the host.
>         * If we don't have active breakpoints in the host, we don't
>         * care about the messed up debug address registers. But if
>         * we have some of them active, restore the old state.
>         */
>        if (hw_breakpoint_active()) {
>                hw_breakpoint_restore();
>        }
> 
> First we need to reload the DRs after we do hw_breakpoint_restore(), no?
> 	vcpu->arch.switch_db_regs |= KVM_DEBUGREG_RELOAD;
> 
> Second, I am unsure whether hw_breakpoint_active() is the correct condition.
> 
> In my defense note that my tests did not his this case since I set affinity
> of the VCPUs to physical cores, and prevented other processes from running.
> 
> Regards,
> Nadav
> 
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
>> On 29/01/2016 23:21, Andrew Vagin wrote:
>>> On Thu, Jan 28, 2016 at 02:42:25PM -0800, Andrey Wagin wrote:
>>>> On Thu, Jan 28, 2016 at 10:33:28PM +0100, Paolo Bonzini wrote:
>>>>> On 28/01/2016 09:31, Andrey Wagin wrote:
>>>>>> I tried to print drX registers after a break-point. Looks like they
>>>>>> are set correctly.
>>>>> 
>>>>> Can you try this KVM patch?
>>>> 
>>>> Looks like it fixes a case when reproducers are running only in VM.
>>> 
>>> Actually Oleg's reproducer detects the bug with this patch when they are
>>> rinning only in VM.
>> 
>> That's actually a good thing, because the patch was a long shot and I
>> had no clue _why_ it would have fixed the bug.  Oleg's reproducer
>> spanning host and a VM actually gives me an idea of what is going on,
>> I'll try to reproduce this week.
>> 
>> Paolo
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [CRIU] x86: Hardware breakpoints are not always triggered
  2016-02-03 23:32           ` Nadav Amit
@ 2016-02-04 11:28             ` Paolo Bonzini
  0 siblings, 0 replies; 12+ messages in thread
From: Paolo Bonzini @ 2016-02-04 11:28 UTC (permalink / raw)
  To: Nadav Amit
  Cc: Andrew Vagin, Andrey Wagin, kvm, Oleg Nesterov, LKML, criu,
	Cyrill Gorcunov



On 04/02/2016 00:32, Nadav Amit wrote:
> Sorry for spamming. The correct fix appears to reload the DRs (set
> KVM_DEBUGREG_RELOAD) in kvm_arch_vcpu_load .

Yup, that was my intended thing to test, but unfortunately I'm
travelling and doing all the testing on the laptop is a bit hard.

Thanks Nadav!!!

Paolo

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2016-02-04 11:28 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-28  8:31 x86: Hardware breakpoints are not always triggered Andrey Wagin
2016-01-28 11:01 ` Jan Kiszka
2016-01-28 20:53 ` Oleg Nesterov
2016-01-28 21:29   ` Paolo Bonzini
2016-01-28 22:01   ` Oleg Nesterov
2016-01-28 21:33 ` Paolo Bonzini
2016-01-28 22:42   ` Andrey Wagin
2016-01-29 22:21     ` [CRIU] " Andrew Vagin
2016-01-31 11:01       ` Paolo Bonzini
2016-02-03 18:18         ` Nadav Amit
2016-02-03 23:32           ` Nadav Amit
2016-02-04 11:28             ` Paolo Bonzini

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.