Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC][PATCH 0/4] x86/entry: disallow #DB more
To:     Peter Zijlstra <peterz@infradead.org>,
        Andy Lutomirski <luto@kernel.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>
References: <20200522204738.645043059@infradead.org>
 <CALCETrV7GYg5V5dgM9BToc6RAqpcjRdoZoeXbnrTKTqjBfft6g@mail.gmail.com>
 <20200523125940.GA2483@worktop.programming.kicks-ass.net>
 <20200523213235.GB4496@worktop.programming.kicks-ass.net>
From:   Rasmus Villemoes <linux@rasmusvillemoes.dk>
Message-ID: <cd2f91e4-aa90-eb98-7f8c-218e8521ac85@rasmusvillemoes.dk>
Date:   Mon, 25 May 2020 12:02:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200523213235.GB4496@worktop.programming.kicks-ass.net>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 23/05/2020 23.32, Peter Zijlstra wrote:
> On Sat, May 23, 2020 at 02:59:40PM +0200, Peter Zijlstra wrote:
>> On Fri, May 22, 2020 at 03:13:57PM -0700, Andy Lutomirski wrote:
> 
>> Good point, so the trivial optimization is below. I couldn't find
>> instruction latency numbers for DRn load/stores anywhere. I'm hoping
>> loads are cheap.
> 
> +	u64 empty = 0, read = 0, write = 0;
> +	unsigned long dr7;
> +
> +	for (i=0; i<100; i++) {
> +		u64 s;
> +
> +		s = rdtsc();
> +		barrier_nospec();
> +		barrier_nospec();
> +		empty += rdtsc() - s;
> +
> +		s = rdtsc();
> +		barrier_nospec();
> +		dr7 = native_get_debugreg(7);
> +		barrier_nospec();
> +		read += rdtsc() - s;
> +
> +		s = rdtsc();
> +		barrier_nospec();
> +		native_set_debugreg(7, 0);
> +		barrier_nospec();
> +		write += rdtsc() - s;
> +	}
> +
> +	printk("XXX: %ld %ld %ld\n", empty, read, write);
> 
> 
> [    1.628125] XXX: 2800 2404 19600
> 
> IOW, reading DR7 is basically free, and certainly cheaper than looking
> at cpu_dr7 which would probably be an insta cache miss.
> 

Naive question: did you check disassembly to see whether gcc threw your
native_get_debugreg() away, given that the asm isn't volatile and the
result is not used for anything? Testing here only shows a "mov
%r9,%db7", but the read did seem to get thrown away.

Rasmus