linux-kernel - Re: [PATCH] perf/x86/amd: Change NMI latency mitigation to use a timestamp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190802162015.GA2349@hirez.programming.kicks-ass.net>
Date:   Fri, 2 Aug 2019 18:20:15 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Lendacky, Thomas" <Thomas.Lendacky@....com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Jiri Olsa <jolsa@...hat.com>,
        Jerry Hoemann <jerry.hoemann@....com>
Subject: Re: [PATCH] perf/x86/amd: Change NMI latency mitigation to use a
 timestamp

On Fri, Aug 02, 2019 at 02:33:41PM +0000, Lendacky, Thomas wrote:
> On 8/1/19 4:59 PM, Thomas Gleixner wrote:
> > On Thu, 1 Aug 2019, Peter Zijlstra wrote:
> >> On Thu, Aug 01, 2019 at 11:34:23PM +0200, Thomas Gleixner wrote:
> >>> Avoid the whole NMI mess, make the PMC interrupt a proper vector in the
> >>> highest prio bucket and instead of using CLI/STI use CR8. That would have
> >>> the additional advantage that we could prevent perf "NMI" then occsionally :)
> >>
> >> Exactly, and not only the PMC, we can basically start giving out actual
> >> vectors on register_nmi_handler() and do away with all that shared line
> >> crap.
> >>
> >> And then the actual NMI line will be mostly empty again, and it can read
> >> its stupid slow reason port again.
> >>
> >> One complication though; IRET et al only do EFLAGS, not CR8, so that's
> >> going to be massive fun :-(
> 
> Talking to the hardware folks, they say setting CR8 is a serializing
> instruction and has to communicate out to the APIC, so it's better to
> use CLI/STI.

Bah; the Intel SDM states: "MOV CR* instructions, except for MOV CR8,
are serializing instructions", which had given me a little hope.

At the same time, all these chips still have the APIC TPR field too, so
much like how the TSC DEADLINE MSR is a hidden APIC write, so too is CR8
I suppose :-(

I'll still finish the patches I started, just to see what it would look
like.

Thomas mentioned combining this with software IRQ disable (like Power),
but at that point maybe full software priorities aren't too bad either.
We'll see.