All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, mlevitsk@redhat.com
Subject: Re: [PATCH v3 0/7] KVM: x86: never write to memory from kvm_vcpu_check_block
Date: Sat, 17 Sep 2022 01:02:59 +0000	[thread overview]
Message-ID: <YyUcw49208H3jgMi@google.com> (raw)
In-Reply-To: <YxoMCp+rMV1ZmRlU@google.com>

On Thu, Sep 08, 2022, Sean Christopherson wrote:
> On Mon, Aug 22, 2022, Paolo Bonzini wrote:
> > The following backtrace:
> > Paolo Bonzini (6):
> >   KVM: x86: check validity of argument to KVM_SET_MP_STATE
> 
> Skipping this one since it's already in 6.0 and AFAICT isn't strictly necessary
> for the rest of the series (shouldn't matter anyways?).
> 
> >   KVM: x86: make vendor code check for all nested events
> >   KVM: x86: lapic does not have to process INIT if it is blocked
> >   KVM: x86: never write to memory from kvm_vcpu_check_block
> >   KVM: mips, x86: do not rely on KVM_REQ_UNHALT
> >   KVM: remove KVM_REQ_UNHALT
> > 
> > Sean Christopherson (1):
> >   KVM: nVMX: Make an event request when pending an MTF nested VM-Exit
> 
> Pushed to branch `for_paolo/6.1` at:
> 
>     https://github.com/sean-jc/linux.git
> 
> with a cosmetic cleanup to kvm_apic_has_events() and the MTF migration fix squashed
> in.

Oh the irony about complaining that people waste maintainers' time by not running
existing tests :-)  I suppose it's not technically ironic since I was the one doing
the actual complaining, but it's still hilarious.

The eponymous patch breaks handling of INITs (and SIPIs) that are "latched"[1]
and later become unblocked, e.g. due to entering VMX non-root mode or because SVM's
GIF is set.  vmx_init_signal_test fails because KVM fails to re-evaluate pending
events after entering guest/non-root.  It passes now because KVM always checks
nested events in the outer run loop.

I have fixes, I'll (temporarily) drop this from the queue and post a new version of
this series on Monday.  As a reward to myself for bisecting and debugging, I'm going
to tweak "KVM: x86: lapic does not have to process INIT if it is blocked" to incorporate
my suggestions[2] from v2 so that the VMX and SVM code can check only for pending
INIT/SIPI and not include the blocking check to align with related checks that also
trigger KVM_REQ_EVENT (and because the resulting SVM GIF code would be quite fragile
if the blocking were incorporated).

[1] It annoys me to no end that KVM uses different terminology for INIT/SIPI versus
    everything else.
[2] https://lore.kernel.org/all/YvwxJzHC5xYnc7CJ@google.com

  reply	other threads:[~2022-09-17  1:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-22 17:06 [PATCH v3 0/7] KVM: x86: never write to memory from kvm_vcpu_check_block Paolo Bonzini
2022-08-22 17:06 ` [PATCH v3 1/7] KVM: x86: check validity of argument to KVM_SET_MP_STATE Paolo Bonzini
2022-08-22 17:06 ` [PATCH v3 2/7] KVM: x86: make vendor code check for all nested events Paolo Bonzini
2022-08-22 17:06 ` [PATCH v3 3/7] KVM: nVMX: Make an event request when pending an MTF nested VM-Exit Paolo Bonzini
2022-08-22 17:52   ` Jim Mattson
2022-08-22 19:40     ` Paolo Bonzini
2022-08-22 17:06 ` [PATCH v3 4/7] KVM: x86: lapic does not have to process INIT if it is blocked Paolo Bonzini
2022-08-22 17:06 ` [PATCH v3 5/7] KVM: x86: never write to memory from kvm_vcpu_check_block Paolo Bonzini
2022-08-22 17:06 ` [PATCH v3 6/7] KVM: mips, x86: do not rely on KVM_REQ_UNHALT Paolo Bonzini
2022-08-22 17:06 ` [PATCH v3 7/7] KVM: remove KVM_REQ_UNHALT Paolo Bonzini
2022-09-08 15:36 ` [PATCH v3 0/7] KVM: x86: never write to memory from kvm_vcpu_check_block Sean Christopherson
2022-09-17  1:02   ` Sean Christopherson [this message]
2022-09-20  1:15     ` Sean Christopherson

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=YyUcw49208H3jgMi@google.com \
    --to=seanjc@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mlevitsk@redhat.com \
    --cc=pbonzini@redhat.com \
    /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.