linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Nick Desaulniers" <ndesaulniers@google.com>,
	"Arnd Bergmann" <arnd@arndb.de>, "Jann Horn" <jannh@google.com>,
	"Randy Dunlap" <rdunlap@infradead.org>,
	"Radim Krčmář" <rkrcmar@redhat.com>
Subject: Re: [PATCH 04/22] x86/kvm: Don't call kvm_spurious_fault() from .fixup
Date: Mon, 15 Jul 2019 20:16:43 +0200	[thread overview]
Message-ID: <585a6828-8a34-143e-52c6-bf2b7f8d2b64@redhat.com> (raw)
In-Reply-To: <20190715132555.3tz4ciogkv3xlkta@treble>

On 15/07/19 15:25, Josh Poimboeuf wrote:
> On Mon, Jul 15, 2019 at 03:05:33PM +0200, Paolo Bonzini wrote:
>> On 15/07/19 14:40, Josh Poimboeuf wrote:
>>>>>   * Hardware virtualization extension instructions may fault if a
>>>>>   * reboot turns off virtualization while processes are running.
>>>>> - * Trap the fault and ignore the instruction if that happens.
>>>>> + * If that happens, trap the fault and panic (unless we're rebooting).
>>>> Not sure the comment is better than before, but apar from that
>>> The previous comment didn't seem to match the code, since we only ignore
>>> the instruction if we're rebooting.
>>>
>>
>> "If that happens" refers to "a reboot turns off virtualization while
>> processes are running".
> 
> Ah, makes sense now.  I was reading "if that happens" to mean the fault.
> 
>>  * Usually after catching the fault we just panic; during reboot
>>  * instead the instruction is ignored.
> 
> Yes, that's much clearer.  Assuming you meant to replace the entire
> comment.

No, I didn't. :)  I meant only the last line (otherwise it removes
information on why the fault may happen and the simplest choice is to
ignore).  Thanks for taking care of this!

Paolo


  I also moved it to directly above the macro it's describing:
> 
> 
> asmlinkage void __noreturn kvm_spurious_fault(void);
> 
> /*
>  * Usually after catching the fault we just panic; during reboot
>  * instead the instruction is ignored.
>  */
> #define ____kvm_handle_fault_on_reboot(insn, cleanup_insn)		\
> 
> 


  reply	other threads:[~2019-07-15 18:16 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-15  0:36 [PATCH 00/22] x86, objtool: several fixes/improvements Josh Poimboeuf
2019-07-15  0:36 ` [PATCH 01/22] x86/paravirt: Fix callee-saved function ELF sizes Josh Poimboeuf
2019-07-15  4:58   ` Juergen Gross
2019-07-15 12:43     ` Josh Poimboeuf
2019-07-15  0:36 ` [PATCH 02/22] x86/kvm: Fix fastop function ELF metadata Josh Poimboeuf
2019-07-15  9:05   ` Paolo Bonzini
2019-07-15  0:36 ` [PATCH 03/22] x86/kvm: Fix frame pointer usage in vmx_vmenter() Josh Poimboeuf
2019-07-15  9:04   ` Paolo Bonzini
2019-07-15 12:37     ` Josh Poimboeuf
2019-07-15 13:03       ` Paolo Bonzini
2019-07-15 13:35         ` Josh Poimboeuf
2019-07-15 18:17           ` Paolo Bonzini
2019-07-15  0:36 ` [PATCH 04/22] x86/kvm: Don't call kvm_spurious_fault() from .fixup Josh Poimboeuf
2019-07-15  9:07   ` Paolo Bonzini
2019-07-15 12:40     ` Josh Poimboeuf
2019-07-15 13:05       ` Paolo Bonzini
2019-07-15 13:25         ` Josh Poimboeuf
2019-07-15 18:16           ` Paolo Bonzini [this message]
2019-07-15  0:37 ` [PATCH 05/22] x86/entry: Fix thunk function ELF sizes Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 06/22] x86/head/64: Annotate start_cpu0() as non-callable Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 07/22] x86/uaccess: Remove ELF function annotation from copy_user_handle_tail() Josh Poimboeuf
2019-07-16 18:16   ` Nick Desaulniers
2019-07-16 18:51     ` Peter Zijlstra
2019-07-15  0:37 ` [PATCH 08/22] x86/uaccess: Don't leak AC flag into fentry from mcsafe_handle_tail() Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 09/22] x86/uaccess: Remove redundant CLACs in getuser/putuser error paths Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 10/22] bpf: Disable GCC -fgcse optimization for ___bpf_prog_run() Josh Poimboeuf
2019-07-16 18:15   ` Nick Desaulniers
2019-07-16 23:02     ` Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 11/22] objtool: Add mcsafe_handle_tail() to the uaccess safe list Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 12/22] objtool: Track original function across branches Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 13/22] objtool: Refactor function alias logic Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 14/22] objtool: Warn on zero-length functions Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 15/22] objtool: Change dead_end_function() to return boolean Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 16/22] objtool: Do frame pointer check before dead end check Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 17/22] objtool: Refactor sibling call detection logic Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 18/22] objtool: Refactor jump table code Josh Poimboeuf
2019-07-15  9:38   ` Peter Zijlstra
2019-07-15  0:37 ` [PATCH 19/22] objtool: Support repeated uses of the same C jump table Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 20/22] objtool: Fix seg fault on bad switch table entry Josh Poimboeuf
2019-07-15 17:24   ` Nick Desaulniers
2019-07-15 17:29     ` Josh Poimboeuf
2019-07-18 23:02       ` Nick Desaulniers
2019-07-15  0:37 ` [PATCH 21/22] objtool: convert insn type to enum Josh Poimboeuf
2019-07-15  0:37 ` [PATCH 22/22] objtool: Support conditional retpolines Josh Poimboeuf
2019-07-15  9:52 ` [PATCH 00/22] x86, objtool: several fixes/improvements Peter Zijlstra
2019-07-15 19:38 ` Josh Poimboeuf
2019-07-15 21:45   ` Nick Desaulniers
2019-07-16 23:17     ` Josh Poimboeuf
2019-07-18 22:26       ` Nick Desaulniers
2019-09-27 20:24         ` Nick Desaulniers

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=585a6828-8a34-143e-52c6-bf2b7f8d2b64@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=arnd@arndb.de \
    --cc=jannh@google.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).