From mboxrd@z Thu Jan  1 00:00:00 1970
From: Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v2 1/2] x86/msr: Carry on after a non-"safe"
 MSR access fails without !panic_on_oops
Date: Mon, 21 Sep 2015 11:47:23 -0700
Message-ID: <CA+55aFz3EnfzC1JEQvFh1pQD8FSSU6Nqr3HH8-y5+bM15m+uCw__29215.4933712029$1442861345$gmane$org@mail.gmail.com>
References: <cover.1442793572.git.luto@kernel.org>
	<130a3b7ef4788baae3a6fe71293ab17442bc9a0a.1442793572.git.luto@kernel.org>
	<CA+55aFy4Chd-PJvxGne=TztPsvFqUG07Ht8mtc4+0oGNZNDOyw@mail.gmail.com>
	<CALCETrXqsKcqzfqMO2ctOJJ4X8Kb6vvoUpVDir9F2-a3XwK23w@mail.gmail.com>
	<20150921084642.GA30984@gmail.com>
	<CA+55aFzKCi6pf0RP8HjDQYDsms6reB5AihuCAHEkVJtoOHk_Yw@mail.gmail.com>
	<CALCETrUBcDxvtjKC-m97GPwCOHvcoDdGjnMJLukSue8ha55mng@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <CALCETrUBcDxvtjKC-m97GPwCOHvcoDdGjnMJLukSue8ha55mng@mail.gmail.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andrew Morton <akpm@linux-foundation.org>, KVM list <kvm@vger.kernel.org>, Peter Zijlstra <peterz@infradead.org>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, xen-devel <Xen-devel@lists.xen.org>, Borislav Petkov <bp@alien8.de>, Paolo Bonzini <pbonzini@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, Arjan van de Ven <arjan@linux.intel.com>, Ingo Molnar <mingo@kernel.org>
List-Id: xen-devel@lists.xenproject.org

On Mon, Sep 21, 2015 at 11:16 AM, Andy Lutomirski <luto@amacapital.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