From: "H. Peter Anvin" Subject: Re: [PATCH] x86: make DR*_RESERVED unsigned long Date: Wed, 24 Apr 2013 18:20:33 -0700 Message-ID: <517884E1.5060404@zytor.com> References: <20130424072630.GB1780@gmail.com> <20130424170702.GA1867@redhat.com> <5178657E.9020905@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Oleg Nesterov , Ingo Molnar , Linus Torvalds , Cyrill Gorcunov , Peter Zijlstra , Thomas Gleixner , David Miller , "Theodore Ts'o" , Linux Kernel Mailing List , the arch/x86 maintainers , Network Development , "linux-ext4@vger.kernel.org" To: Frederic Weisbecker Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org On 04/24/2013 04:31 PM, Frederic Weisbecker wrote: >> >> Now, DR6 is a bit special in that a bunch of the reserved bits are >> hardwired to 1, not 0; I don't know offhand if that is true for bits >> [63:32]. > > Hmm, good point, could it be a problem given that we clear the > reserved dr6 bits on do_trap() and write that 'cleaned up" value back > to "tsk->thread.debugreg6"? Probably not if those hardwired reserved > bits are set to "1" on dr6 physical write whether those bits are > cleared or not in their storage in thread struct before resuming the > task? > OK, the SDM states that DR6[63:32] are reserved and must be written as zero (not one). So the quiescent 64-bit value of DR6 is 0x0000_0000_FFFF_0FF0. -hpa