[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXhgmkRNaZq9QFWjVVYiX+t=ML_e-oDw2PPEFxQdoA+6Q@mail.gmail.com>
Date: Mon, 3 Aug 2020 08:15:02 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Josh Poimboeuf <jpoimboe@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>, mbenes@...e.de,
LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
Juergen Gross <jgross@...e.com>
Subject: Re: [RFC][PATCH] objtool,x86_64,paravirt: Add pv_ops[] support
On Mon, Aug 3, 2020 at 7:33 AM <peterz@...radead.org> wrote:
>
>
> Thomas wanted paramuck vs noinstr, here goes. Very rough, very nasty,
> mostly works.
>
> It requires call sites are the normal indirect call, and not mangled
> retpoison (slow_down_io() had those), it also requires pv_ops[]
> assignments are single instructions and not laundered through some
> pointless intermediate helper (hyperv).
>
> It doesn't warn when you get any of that wrong.
>
> But if you have it all lined up right, it will warn about noinstr
> violations due to paramuck:
I certainly agree that pv_ops is mucky, but could you expound on
precisely what this patch actually does? On a very quick
read-through, I'm guessing you're complaining about any call to pv_ops
in a noinstr section? But maybe this is only calls to pv_ops that
aren't themselves noinstr?
Powered by blists - more mailing lists