From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>
Cc: KVM list <kvm@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
xen-devel <Xen-devel@lists.xen.org>,
Borislav Petkov <bp@alien8.de>,
Paolo Bonzini <pbonzini@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
Arjan van de Ven <arjan@linux.intel.com>
Subject: Re: [Xen-devel] [PATCH v4 0/5] [PATCH v3 0/5] Improve non-"safe" MSR access failure handling
Date: Mon, 14 Mar 2016 10:32:13 -0400 [thread overview]
Message-ID: <56E6CB6D.5080906@oracle.com> (raw)
In-Reply-To: <cover.1457805972.git.luto@kernel.org>
On 03/12/2016 01:08 PM, Andy Lutomirski wrote:
> Setting CONFIG_PARAVIRT=y has an unintended side effect: it silently
> turns all rdmsr and wrmsr operations into the safe variants without
> any checks that the operations actually succeed.
>
> With CONFIG_PARAVIRT=n, unchecked MSR failures OOPS and probably
> cause boot to fail if they happen before init starts.
>
> Neither behavior is very good, and it's particularly unfortunate that
> the behavior changes depending on CONFIG_PARAVIRT.
>
> In particular, KVM guests might be unwittingly depending on the
> PARAVIRT=y behavior because CONFIG_KVM_GUEST currently depends on
> CONFIG_PARAVIRT, and, because accesses in that case are completely
> unchecked, we wouldn't even see a warning.
>
> This series changes the native behavior, regardless of
> CONFIG_PARAVIRT. A non-"safe" MSR failure will give an informative
> warning once and will be fixed up -- native_read_msr will return
> zero, and both reads and writes will continue where they left off.
>
> If panic_on_oops is set, they will still OOPS and panic.
>
> By using the shiny new custom exception handler infrastructure,
> there should be no overhead on the success paths.
>
> I didn't change the behavior on Xen, but, with this series applied,
> it would be straightforward for the Xen maintainers to make the
> corresponding change -- knowledge of whether the access is "safe" is
> now propagated into the pvops.
>
> Doing this is probably a prerequisite to sanely decoupling
> CONFIG_KVM_GUEST and CONFIG_PARAVIRT, which would probably make
> Arjan and the rest of the Clear Containers people happy :)
>
> There's also room to reduce the code size of the "safe" variants
> using custom exception handlers in the future.
>
> Changes from v3:
> - WARN_ONCE instead of WARN (Ingo)
> - In the warning text, s/unsafe/unchecked/ (Ingo, sort of)
>
> Changes from earlier versions: lots of changes!
>
> Andy Lutomirski (5):
> x86/paravirt: Add _safe to the read_msr and write_msr PV hooks
> x86/msr: Carry on after a non-"safe" MSR access fails without
> !panic_on_oops
> x86/paravirt: Add paravirt_{read,write}_msr
> x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y
> x86/msr: Set the return value to zero when native_rdmsr_safe fails
>
> arch/x86/include/asm/msr.h | 20 ++++++++++++----
> arch/x86/include/asm/paravirt.h | 45 +++++++++++++++++++++--------------
> arch/x86/include/asm/paravirt_types.h | 14 +++++++----
> arch/x86/kernel/paravirt.c | 6 +++--
> arch/x86/mm/extable.c | 33 +++++++++++++++++++++++++
> arch/x86/xen/enlighten.c | 27 +++++++++++++++++++--
> 6 files changed, 114 insertions(+), 31 deletions(-)
>
I don't see any issues as far as Xen is concerned but let me run this
through our nightly. I'll wait for the next version (which I think you
might have based on the comments). Please copy me.
-boris
next prev parent reply other threads:[~2016-03-14 14:33 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-12 18:08 [PATCH v4 0/5] [PATCH v3 0/5] Improve non-"safe" MSR access failure handling Andy Lutomirski
2016-03-12 18:08 ` [PATCH v4 1/5] x86/paravirt: Add _safe to the read_msr and write_msr PV hooks Andy Lutomirski
2016-03-14 11:57 ` Borislav Petkov
2016-03-14 11:57 ` Borislav Petkov
2016-03-14 17:07 ` Andy Lutomirski
2016-03-14 17:07 ` Andy Lutomirski
2016-03-12 18:08 ` Andy Lutomirski
2016-03-12 18:08 ` [PATCH v4 2/5] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops Andy Lutomirski
2016-03-12 18:08 ` Andy Lutomirski
2016-03-14 12:02 ` Borislav Petkov
2016-03-14 12:02 ` Borislav Petkov
2016-03-14 17:05 ` Andy Lutomirski
2016-03-14 17:11 ` Linus Torvalds
2016-03-14 17:17 ` Andy Lutomirski
2016-03-14 17:17 ` Andy Lutomirski
2016-03-14 18:04 ` Linus Torvalds
2016-03-14 18:10 ` Andy Lutomirski
2016-03-14 18:10 ` Andy Lutomirski
2016-03-14 18:15 ` Linus Torvalds
2016-03-14 18:15 ` Linus Torvalds
2016-03-14 18:24 ` Andy Lutomirski
2016-03-14 18:40 ` Linus Torvalds
2016-03-14 18:48 ` Andy Lutomirski
2016-03-14 18:48 ` Andy Lutomirski
2016-03-15 10:22 ` Ingo Molnar
2016-03-15 10:22 ` Ingo Molnar
2016-03-15 10:26 ` Ingo Molnar
2016-03-15 10:26 ` Ingo Molnar
2016-03-14 18:40 ` Linus Torvalds
2016-03-14 18:24 ` Andy Lutomirski
2016-03-14 20:18 ` Peter Zijlstra
2016-03-14 20:18 ` Peter Zijlstra
2016-03-14 18:10 ` Linus Torvalds
2016-03-14 18:10 ` Linus Torvalds
2016-03-15 10:21 ` Ingo Molnar
2016-03-15 10:21 ` Ingo Molnar
2016-03-14 18:04 ` Linus Torvalds
2016-03-14 17:05 ` Andy Lutomirski
2016-03-12 18:08 ` [PATCH v4 3/5] x86/paravirt: Add paravirt_{read,write}_msr Andy Lutomirski
2016-03-12 18:08 ` [PATCH v4 3/5] x86/paravirt: Add paravirt_{read, write}_msr Andy Lutomirski
2016-03-12 18:08 ` [PATCH v4 4/5] x86/paravirt: Make "unsafe" MSR accesses unsafe even if PARAVIRT=y Andy Lutomirski
2016-03-12 18:08 ` Andy Lutomirski
2016-03-12 18:08 ` [PATCH v4 5/5] x86/msr: Set the return value to zero when native_rdmsr_safe fails Andy Lutomirski
2016-03-12 18:08 ` Andy Lutomirski
2016-03-14 14:32 ` Boris Ostrovsky [this message]
2016-03-14 14:32 ` [PATCH v4 0/5] [PATCH v3 0/5] Improve non-"safe" MSR access failure handling Boris Ostrovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56E6CB6D.5080906@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=Xen-devel@lists.xen.org \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=bp@alien8.de \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.