Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 11 Nov 2022 14:22:12 -0800
From:   "H. Peter Anvin" <hpa@zytor.com>
To:     Andrew Cooper <Andrew.Cooper3@citrix.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Paolo Bonzini <pbonzini@redhat.com>
CC:     "Li, Xin3" <xin3.li@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "x86@kernel.org" <x86@kernel.org>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "tglx@linutronix.de" <tglx@linutronix.de>,
        "mingo@redhat.com" <mingo@redhat.com>,
        "bp@alien8.de" <bp@alien8.de>,
        "dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
        "Christopherson,, Sean" <seanjc@google.com>,
        Kevin Tian <kevin.tian@intel.com>
Subject: =?US-ASCII?Q?Re=3A_=5BRESEND_PATCH_5/6=5D_KVM=3A_x86/VMX=3A_add_kvm=5F?= =?US-ASCII?Q?vmx=5Freinject=5Fnmi=5Firq=28=29_for_NMI/IRQ_reinjection?=
User-Agent: K-9 Mail for Android
In-Reply-To: <0b5798d6-aa1d-8ad8-b129-9cffdfd4e5da@citrix.com>
References: <20221110061545.1531-1-xin3.li@intel.com> <20221110061545.1531-6-xin3.li@intel.com> <Y2y+YgBUYuUHbPtd@hirez.programming.kicks-ass.net> <BN6PR1101MB2161976800EB14B74A24D9F3A8019@BN6PR1101MB2161.namprd11.prod.outlook.com> <Y24SoNKZtj/NPSGy@hirez.programming.kicks-ass.net> <6097036e-063f-5175-72b2-8935b12af853@redhat.com> <Y24908NWCdzUNqI0@hirez.programming.kicks-ass.net> <6fd26a70-3774-6ae7-73ea-4653aee106f0@redhat.com> <Y25a0Z2tOMWYZs4j@hirez.programming.kicks-ass.net> <0b5798d6-aa1d-8ad8-b129-9cffdfd4e5da@citrix.com>
Message-ID: <8D824B88-1EBB-4CEC-9D1D-89123D536500@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On November 11, 2022 8:35:30 AM PST, Andrew Cooper <Andrew=2ECooper3@citrix=
=2Ecom> wrote:
>On 11/11/2022 14:23, Peter Zijlstra wrote:
>> On Fri, Nov 11, 2022 at 01:48:26PM +0100, Paolo Bonzini wrote:
>>> On 11/11/22 13:19, Peter Zijlstra wrote:
>>>> On Fri, Nov 11, 2022 at 01:04:27PM +0100, Paolo Bonzini wrote:
>>>>> On Intel you can optionally make it hold onto IRQs, but NMIs are alw=
ays
>>>>> eaten by the VMEXIT and have to be reinjected manually=2E
>>>> That 'optionally' thing worries me -- as in, KVM is currently
>>>> opting-out?
>>> Yes, because "If the =E2=80=9Cprocess posted interrupts=E2=80=9D VM-ex=
ecution control is 1,
>>> the =E2=80=9Cacknowledge interrupt on exit=E2=80=9D VM-exit control is=
 1" (SDM 26=2E2=2E1=2E1,
>>> checks on VM-Execution Control Fields)=2E  Ipse dixit=2E  Posted inter=
rupts are
>>> available and used on all processors since I think Ivy Bridge=2E
>
>On server SKUs=2E=C2=A0 Client only got "virtual interrupt processing" fa=
irly
>recently IIRC, which is the CPU-side property which matters=2E
>
>> (imagine the non-coc compliant reaction here)
>>
>> So instead of fixing it, they made it worse :-(
>>
>> And now FRED is arguably making it worse again, and people wonder why I
>> hate virt=2E=2E=2E
>
>The only FRED-compatible fix is to send a self-NMI, because because you
>may need a CSL change too=2E
>
>VT-x *does* hold the NMI latch (for VMEXIT_REASON NMI), so it's self-NMI
>and then enable_nmi()s=2E
>
>Except the IRET to self won't work - it will need to be ERETS-to-self=2E=
=C2=A0
>Which I think is fine=2E
>
>But what isn't fine is the fact that a self-NMI doesn't deliver
>synchronously, so you need to wait until it is pending, before enabling
>NMIs=2E=C2=A0 (Well, actually you need to ensure that it's definitely del=
ivered
>before re-entering the VM)=2E
>
>And I'm totally out of ideas here=2E=2E=2E
>
>~Andrew
>

There is no fundamental reason to do a CSL/IST change if you happen to kno=
w a priori that the stack is in a valid state to have the NMI frame on it; =
that is:

1=2E Not deep into a nested I/O layer;
2=2E Valid, and not in flux in any way=2E

Since this reinject will always be in a well-defined location, that's fine=
=2E

So I think *that* concern is not actually an issue=2E

Again, note that this is not a FRED-specific problem=2E