Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <YJG6ztbGjtuctec4@google.com> <38B9D60F-F24F-4910-B2DF-2A57F1060452@amacapital.net>
In-Reply-To: <38B9D60F-F24F-4910-B2DF-2A57F1060452@amacapital.net>
From:   Lai Jiangshan <jiangshanlai@gmail.com>
Date:   Wed, 5 May 2021 09:07:50 +0800
Message-ID: <CAJhGHyDsTVyDX9fkYAyVkVQFWqkyTAVCY4enJqdG4bzOuOSn+w@mail.gmail.com>
Subject: Re: [PATCH] KVM/VMX: Invoke NMI non-IST entry instead of IST entry
To:     Andy Lutomirski <luto@amacapital.net>
Cc:     Sean Christopherson <seanjc@google.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Maxim Levitsky <mlevitsk@redhat.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        LKML <linux-kernel@vger.kernel.org>,
        Lai Jiangshan <laijs@linux.alibaba.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Andi Kleen <ak@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Uros Bizjak <ubizjak@gmail.com>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Alexandre Chartre <alexandre.chartre@oracle.com>,
        Juergen Gross <JGross@suse.com>,
        Joerg Roedel <jroedel@suse.de>, Jian Cai <caij2003@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, May 5, 2021 at 5:23 AM Andy Lutomirski <luto@amacapital.net> wrote:
>
>
> > On May 4, 2021, at 2:21 PM, Sean Christopherson <seanjc@google.com> wro=
te:
> >
> > =EF=BB=BFOn Tue, May 04, 2021, Paolo Bonzini wrote:
> >>> On 04/05/21 23:05, Maxim Levitsky wrote:
> >>> Does this mean that we still rely on hardware NMI masking to be activ=
ated?
> >>
> >> No, the NMI code already handles reentrancy at both the assembly and C
> >> levels.
> >>
> >>> Or in other words, that is we still can't have an IRET between VM exi=
t and
> >>> the entry to the NMI handler?
> >>
> >> No, because NMIs are not masked on VM exit.  This in fact makes things
> >> potentially messy; unlike with AMD's CLGI/STGI, only MSRs and other th=
ings
> >> that Intel thought can be restored atomically with the VM exit.
> >
> > FWIW, NMIs are masked if the VM-Exit was due to an NMI.
>
> Then this whole change is busted, since nothing will unmask NMIs. Revert =
it?

There is some instructable code between VMEXIT and
handle_exception_nmi_irqoff().

The possible #DB #BP can happen in this gap and the IRET
of the handler of #DB #BP will unmask NMI.

Another way to fix is to change the VMX code to call the NMI handler
immediately after VMEXIT before leaving "nostr" section.

Reverting it can't fix the problem.