Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1320413 > unrolled thread

x86: Hardware breakpoints are not always triggered

Back to article view | Back to linux.kernel

Contents

  x86: Hardware breakpoints are not always triggered Andrey Wagin <avagin@gmail.com> - 2016-01-28 09:40 +0100
    Re: x86: Hardware breakpoints are not always triggered Jan Kiszka <jan.kiszka@siemens.com> - 2016-01-28 12:10 +0100
    Re: x86: Hardware breakpoints are not always triggered Oleg Nesterov <oleg@redhat.com> - 2016-01-28 22:00 +0100
      Re: x86: Hardware breakpoints are not always triggered Paolo Bonzini <pbonzini@redhat.com> - 2016-01-28 22:30 +0100
      Re: x86: Hardware breakpoints are not always triggered Oleg Nesterov <oleg@redhat.com> - 2016-01-28 23:10 +0100
    Re: x86: Hardware breakpoints are not always triggered Paolo Bonzini <pbonzini@redhat.com> - 2016-01-28 22:40 +0100
      Re: x86: Hardware breakpoints are not always triggered Andrey Wagin <avagin@gmail.com> - 2016-01-28 23:50 +0100
        Re: [CRIU] x86: Hardware breakpoints are not always triggered Andrew Vagin <avagin@virtuozzo.com> - 2016-01-29 23:30 +0100
          Re: [CRIU] x86: Hardware breakpoints are not always triggered Paolo Bonzini <pbonzini@redhat.com> - 2016-01-31 12:10 +0100
            Re: [CRIU] x86: Hardware breakpoints are not always triggered Nadav Amit <nadav.amit@gmail.com> - 2016-02-03 19:20 +0100
              Re: [CRIU] x86: Hardware breakpoints are not always triggered Nadav Amit <nadav.amit@gmail.com> - 2016-02-04 00:40 +0100
                Re: [CRIU] x86: Hardware breakpoints are not always triggered Paolo Bonzini <pbonzini@redhat.com> - 2016-02-04 12:30 +0100

#1320413 — x86: Hardware breakpoints are not always triggered

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#1320561

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

[toc] | [prev] | [next] | [standalone]

#1321050

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.

[toc] | [prev] | [next] | [standalone]

#1321074

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

[toc] | [prev] | [next] | [standalone]

#1321097

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;
}

[toc] | [prev] | [next] | [standalone]

#1321079

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

[toc] | [prev] | [next] | [standalone]

#1321120

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

[toc] | [prev] | [next] | [standalone]

#1322131 — Re: [CRIU] x86: Hardware breakpoints are not always triggered

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

[toc] | [prev] | [next] | [standalone]

#1322605 — Re: [CRIU] x86: Hardware breakpoints are not always triggered

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

[toc] | [prev] | [next] | [standalone]

#1325795 — Re: [CRIU] x86: Hardware breakpoints are not always triggered

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

[toc] | [prev] | [next] | [standalone]

#1326211 — Re: [CRIU] x86: Hardware breakpoints are not always triggered

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

[toc] | [prev] | [next] | [standalone]

#1326691 — Re: [CRIU] x86: Hardware breakpoints are not always triggered

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web