Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp3558409pxy; Mon, 26 Apr 2021 04:46:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwZy+YqxBlR5F/mV6KjGLdKopLkYBbZ5iDjFrwpJVaN6tQjWsOcGoW+5R9ILBG9hmZPBbYg X-Received: by 2002:aa7:92cb:0:b029:1f1:542f:2b2b with SMTP id k11-20020aa792cb0000b02901f1542f2b2bmr16967238pfa.31.1619437589952; Mon, 26 Apr 2021 04:46:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619437589; cv=none; d=google.com; s=arc-20160816; b=r3mzX+xINZ1viFt6hsLKNV3kWQH9L9aC2Ik2PvJEACVBF7MNj+c9hB/T+B7sVYTEJf PSiaWm/WSmlcYh/HJr7MgggbfQxgWc5JS2X4rIYR7qKZj2pJEGMIhTLUu2cVcke+9gna Qrg8g6SLHAwQyz/hvKI6HrGAYgkppk+aGo936THft+ZMOdpfsx/D3n5Fql+MvO/FTu6/ n5X1P1VjzkqZFVZiOOOHT7IsMJTDOm7Jf2ubmoDutqUnlNe9/i2FL3/xQlV5z3zZTCKK /ZVQ27ww/+PPCBQIo2yRrs65/ealA4t2wqFEJHEEGoMZ8P5tRYB1W3+FxizNPOoHpXep lbLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id:dkim-signature; bh=865sj3XQejk5FU8PQVUkGqm7BiqNpbV7oX+eaAy7hAk=; b=hmIt2TKbRZBHjc28Wuu9G2mrV4GMKUQNlH9IeG4NQslqm5GdqI97du3/ERrGyN1w3E g1hcZYkqWCQpFvCeDtEV5jO/xqGjfF6XGTNyqK0k1Q52HSvQpFiOmoXWJs+TF7nD7cAR QJSydnUAhfBk19ademthK/Nx1fV3O4f4dFfLur1CToJOGQtHI2re8qZYL8eMsJ9TAwqG fVhb9t3S/GU+cMOJ2mYcSaNmKU++1fOqjZpuYjkiXsR641KSMoQlHzKoGcz6xEG0GMpo UaMvCMfIdrFRgywqNNSy+yWEeK8i3WRPRlhDoi+x1KlqIt0b4ttOwyIYCMAaYN6lF1BC HHNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=e3GTmi84; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t15si21416921pgm.255.2021.04.26.04.46.16; Mon, 26 Apr 2021 04:46:29 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=e3GTmi84; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231978AbhDZLpo (ORCPT + 99 others); Mon, 26 Apr 2021 07:45:44 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:30204 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231903AbhDZLpn (ORCPT ); Mon, 26 Apr 2021 07:45:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619437501; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=865sj3XQejk5FU8PQVUkGqm7BiqNpbV7oX+eaAy7hAk=; b=e3GTmi84/ADZENS8jrktTGxSrN8HexUN7bg2+NSzHnt325mbs5wvBIpGeIxGwZZy9BSYks Pay/bALDjlWhc2EuqTCisq5t+RguwPErgk1Bvp3cs/PGTrB7XliB6wntcXJ4BYrSvUetXE oR3KnK1fINuRk8JP6wVg08fm/nEvAQ0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-373-VguNjZYqM9KRR0IVKdo5iw-1; Mon, 26 Apr 2021 07:44:57 -0400 X-MC-Unique: VguNjZYqM9KRR0IVKdo5iw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7259D343A5; Mon, 26 Apr 2021 11:44:55 +0000 (UTC) Received: from starship (unknown [10.40.192.73]) by smtp.corp.redhat.com (Postfix) with ESMTP id 86EB660BE5; Mon, 26 Apr 2021 11:44:50 +0000 (UTC) Message-ID: Subject: Re: [PATCH v2 2/2] KVM: VMX: Invoke NMI handler via indirect call instead of INTn From: Maxim Levitsky To: Paolo Bonzini , Lai Jiangshan , Sean Christopherson Cc: Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, LKML , Josh Poimboeuf , Uros Bizjak , Andi Kleen , Andy Lutomirski , Steven Rostedt Date: Mon, 26 Apr 2021 14:44:49 +0300 In-Reply-To: References: <20200915191505.10355-1-sean.j.christopherson@intel.com> <20200915191505.10355-3-sean.j.christopherson@intel.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-2.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2021-04-26 at 12:40 +0200, Paolo Bonzini wrote: > On 26/04/21 11:33, Lai Jiangshan wrote: > > When handle_interrupt_nmi_irqoff() is called, we may lose the > > CPU-hidden-NMI-masked state due to IRET of #DB, #BP or other traps > > between VMEXIT and handle_interrupt_nmi_irqoff(). > > > > But the NMI handler in the Linux kernel*expects* the CPU-hidden-NMI-masked > > state is still set in the CPU for no nested NMI intruding into the beginning > > of the handler. > > > > The original code "int $2" can provide the needed CPU-hidden-NMI-masked > > when entering #NMI, but I doubt it about this change. > > How would "int $2" block NMIs? The hidden effect of this change (and I > should have reviewed better the effect on the NMI entry code) is that > the call will not use the IST anymore. > > However, I'm not sure which of the two situations is better: entering > the NMI handler on the IST without setting the hidden NMI-blocked flag > could be a recipe for bad things as well. If I understand this correctly, we can't really set the NMI blocked flag on Intel, but only keep it from beeing cleared by an iret after it was set by the intercepted NMI. Thus the goal of this patchset was to make sure that we don't call any interrupt handlers that can do iret before we call the NMI handler Indeed I don't think that doing int $2 helps, unless I miss something. We just need to make sure that we call the NMI handler as soon as possible. If only Intel had the GI flag.... My 0.2 cents. Best regards, Maxim Levitsky > > Paolo >