[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFz3EnfzC1JEQvFh1pQD8FSSU6Nqr3HH8-y5+bM15m+uCw@mail.gmail.com>
Date: Mon, 21 Sep 2015 11:47:23 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andy Lutomirski <luto@...capital.net>
Cc: Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Paolo Bonzini <pbonzini@...hat.com>,
xen-devel <Xen-devel@...ts.xen.org>,
Arjan van de Ven <arjan@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
KVM list <kvm@...r.kernel.org>,
"the arch/x86 maintainers" <x86@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access
fails without !panic_on_oops
On Mon, Sep 21, 2015 at 11:16 AM, Andy Lutomirski <luto@...capital.net> wrote:
>
> In the interest of sanity, I want to drop the "native_", too
Yes. I think the only reason it exists is to have that wrapper layer
for PV. And that argument just goes away if you just make the
non-inline helper function do all the PV logic directly.
I really suspect we should do this for a *lot* of the PV ops. Yeah,
some are so performance-critical that we probably do have a good
reason for the inline indirections etc (historical example: native
spin-unlock, which traditionally could be done as a single store
instruction), but I suspect a lot of the PV indirection is for this
kind of "historical wrapper model" reason, and it often makes it
really hard to see what is going on because you have to go through
several layers of indirection, often in different files.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists