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;
MIME-Version: 1.0
References: <20200522204738.645043059@infradead.org>
In-Reply-To: <20200522204738.645043059@infradead.org>
From:   Andy Lutomirski <luto@kernel.org>
Date:   Fri, 22 May 2020 15:13:57 -0700
Message-ID: <CALCETrV7GYg5V5dgM9BToc6RAqpcjRdoZoeXbnrTKTqjBfft6g@mail.gmail.com>
Subject: Re: [RFC][PATCH 0/4] x86/entry: disallow #DB more
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, May 22, 2020 at 1:49 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> Hai, this kills #DB during NMI/#MC and with that allows removing all the nasty
> IST rewrite crud.
>

This is great, except that the unconditional DR7 write is going to
seriously hurt perf performance.  Fortunately, no one cares about
perf, right? :)  Even just reading first won't help enough because DR7
reads are likely to be VM exits.  Can we have a percpu dr7 shadow
(with careful ordering) or even just a percpu count of dr7 users so we
can skip this if there are no breakpoints?  We have cpu_dr7, and some
minor changes would make this work.  Maybe replace all the direct
cpu_dr7 access with helpers like dr7_set_bits() and dr7_clear_bits()?

Also, I like raving at DR7 :)