All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: Nadav Amit <namit@cs.technion.ac.il>,
	pbonzini@redhat.com, kvm@vger.kernel.org
Subject: Re: [PATCH 1/6] KVM: x86: DR7.GD should be cleared upon any #DB exception
Date: Wed, 1 Oct 2014 21:22:31 +0200	[thread overview]
Message-ID: <20141001192230.GE12083@potion.brq.redhat.com> (raw)
In-Reply-To: <05CDC095-E68B-4BB0-94DE-1BC3202C4217@gmail.com>

2014-10-01 21:22+0300, Nadav Amit:
> 
> On Oct 1, 2014, at 6:24 PM, Radim Krčmář <rkrcmar@redhat.com> 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@redhat.com>

  reply	other threads:[~2014-10-01 19:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30 17:49 [PATCH 0/6] KVM: x86: Miscellaneous bug fixes Nadav Amit
2014-09-30 17:49 ` [PATCH 1/6] KVM: x86: DR7.GD should be cleared upon any #DB exception Nadav Amit
2014-10-01 15:24   ` Radim Krčmář
2014-10-01 18:22     ` Nadav Amit
2014-10-01 19:22       ` Radim Krčmář [this message]
2014-09-30 17:49 ` [PATCH 2/6] KVM: x86: Wrong error code on limit violation during emulation Nadav Amit
2014-10-01 15:44   ` Radim Krčmář
2014-10-27 14:37   ` Paolo Bonzini
2014-10-27 14:46     ` Nadav Amit
2014-10-27 14:48       ` Paolo Bonzini
2014-09-30 17:49 ` [PATCH 3/6] KVM: x86: NoBigReal was mistakenly considering la instead of ea Nadav Amit
2014-10-01 15:58   ` Radim Krčmář
2014-10-02 14:52     ` Nadav Amit
2014-10-03 12:50       ` Radim Krčmář
2014-10-06 15:19         ` Nadav Amit
2014-09-30 17:49 ` [PATCH 4/6] KVM: x86: Fix determining flat mode in recalculate_apic_map Nadav Amit
2014-10-01 16:04   ` Radim Krčmář
2014-10-01 17:30     ` Nadav Amit
2014-10-01 18:27       ` Radim Krčmář
2014-10-01 19:16         ` Nadav Amit
2014-10-01 20:58           ` Radim Krčmář
2014-10-04  6:50   ` Gleb Natapov
2014-09-30 17:49 ` [PATCH 5/6] KVM: x86: Wrong assertion on paging_tmpl.h Nadav Amit
2014-10-01 16:26   ` Radim Krčmář
2014-10-01 17:14     ` Nadav Amit
2014-10-01 17:54       ` Radim Krčmář
2014-10-08  9:17       ` Paolo Bonzini
2014-09-30 17:49 ` [PATCH 6/6] KVM: x86: Emulator does not calculate address correctly Nadav Amit
2014-10-01 17:21   ` Radim Krčmář

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=20141001192230.GE12083@potion.brq.redhat.com \
    --to=rkrcmar@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=nadav.amit@gmail.com \
    --cc=namit@cs.technion.ac.il \
    --cc=pbonzini@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.