2014-10-01 21:22+0300, Nadav Amit: > > On Oct 1, 2014, at 6:24 PM, Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote: > > > 2014-09-30 20:49+0300, Nadav Amit: > >> Intel SDM 17.2.4 (Debug Control Register (DR7)) says: "The processor clears the > >> GD flag upon entering to the debug exception handler." This sentence may be > >> misunderstood as if it happens only on #DB due to debug-register protection, > >> but it happens regardless to the cause of the #DB. > > > > All real hardware behaves that way? > I have no way of knowing. :) > I know Intel’s phrasing is misleading, so I verified this behaviour in two ways: > 1. I changed KVM not to trap #DB. I then changed kvm-unit-tests/debug.c to set DR7.GD prior to the watchpoint test, and printed once I entered the handler, before any DR was accessed by the handler. > The result: we entered the handler once (afterwards I printed DR7 and saw GD is indeed clear). If #DB due to watchpoint did not clear GD, we would enter the handler twice. Thanks. > 2. I looked at bochs: https://github.com/larsr/bochs-svn/blob/master/cpu/exception.cc : > > if (vector == BX_DB_EXCEPTION) { > // Commit debug events to DR6: preserve DR5.BS and DR6.BD values, > // only software can clear them > BX_CPU_THIS_PTR dr6.val32 = (BX_CPU_THIS_PTR dr6.val32 & 0xffff6ff0) | > (BX_CPU_THIS_PTR debug_trap & 0x0000e00f); > > // clear GD flag in the DR7 prior entering debug exception handler > BX_CPU_THIS_PTR dr7.set_GD(0); > } (Ok.) > The behaviour seems reasonable to me. Otherwise the CPU would re-enter the handler when the handler inspects DR6. It usually is sufficient just to read it, but yeah, re-entry for the general usage isn't nice either. To the patch itself: We could use kvm_x86_ops->set_dr7() directly, but maybe we are going to do something with on GD bit, so Reviewed-by: Radim Krčmář <rkrcmar@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
