Re: [x86] only print out DR registers if they are not power-ondefaults.

From: Borislav Petkov
Date: Thu Jun 20 2013 - 01:29:28 EST

On Wed, Jun 19, 2013 at 03:02:19PM -0700, H. Peter Anvin wrote:
> On 06/19/2013 02:52 PM, Borislav Petkov wrote:
> > On Wed, Jun 19, 2013 at 02:42:49PM -0700, H. Peter Anvin wrote:
> >> There is serious confusion with regards to DR6 about the bits which
> >> are *fixed* (forced to 1) and the ones which are *reserved* (should
> >> always have a fixed value.)
> >>
> >> There are some bits in DR6 which are used by hardware probes.
> >
> > Haha, I knew it! HW guys don't care about the architectural documents.
> >
> > Maybe DR6 should probably be dropped altogether from the check before
> > exiting __show_regs early?
> Uhm... I think you're missing the point of architectural documents.
> The architectural documents describe the contract between hardware and
> software. It doesn't mean that hardware can't go beyond it... it is in
> fact the norm. The architectural documentation states what software may
> rely on and within what bounds it can assume safe behavior to be
> compatible both now and with any future extensions.

Well, that I know :).

>From your comment above it sounded like we can't really rely on some of
the bits in DR6_RESERVED to be really always 1 as they cannot only be
*fixed* (forced to 1) but also be reserved with a fixed value which is
not necessarily 1.

And there's a section in the SDM "19.23.1 Differences in Debug Register
DR6" which says that some families allow writes to 1b of bit 12 while
others don't.

Now Dave stated earlier "I occasionally see DR6: 00000000fffe0ff0 for
eg." which says that bit 16 can be 0b but the AMD spec says "read as 1s"
and Intel's spec says "Reserved (set to 1)" which I only assume is the
same thing: the default state of those is 1.

So maybe the DR6 check should be reversed to actually look at only the
defined bits and ignore "volatile" reserved bits, whichever they might
be :-):

if (!(dr6 & 0xe00f))

I.e., bit slices [15:13] and [3:0] should be 0.

Then we can assume no breakpoint condition has been detected nor the
debug registers are being used in some way.


Sent from a fat crate under my desk. Formatting is fine.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at