Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp3515062pxy; Mon, 26 Apr 2021 03:42:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxVTs6O1heyv2CCdhbGMGWOAiWzRm3Wc4qWjmAxZb2NU00dkeNbuxwOTQnz2ew4VU03dRas X-Received: by 2002:a05:6402:31ac:: with SMTP id dj12mr20236619edb.267.1619433761238; Mon, 26 Apr 2021 03:42:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619433761; cv=none; d=google.com; s=arc-20160816; b=l7JtelNYKus5Y02EPDVcHuVMH3GvOmOgQEDS8ci+aT0BLqV7UsQksNkDRZ5YxcS1eV qo7q0a642s8TLPya0ZixxR3P7rwnodiiYKqI5cM+pzSYQH3tUnJOrFFJlc9Ndxi05j5Q uXxTay68XCErVC3e7bTPMQrT4/AL2ghbUHH4mrieGSlnS1Sxw0s3XUC+NyMi8aralaD6 KQ58WXTWh8Xy1yoOo3y+WOAzaNNonuLVLPgmkePYVOONIeGT94TmodrJNEa8K08a0bOl DLpEI02UJKdls7jQ05bCJ6J6TKbMad3yxy4KXXmFm78PCOqopkunPkkDQDcbq9Sh0k5a mCoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=bZZsUMt0KMjKP40YJJFPdYzvGN9VTk6y13Ps6YXhbp8=; b=WisubNU2Ov7i0fHfR6M54uff+/YCDu8ozINsb4rjLdUtZkN4YKZNKt4OSfbTKpf8kD zuWThnCD4UgkeXhrfmNeFbnpMIBj5NWe4qfocV/R+YTW4POOT76pqka4G5yE4Z3S2Op7 6Fbdz8UBUifBpLN9jBBF07HjSmzTjH/pENPiLk/8qwngyRaymURMLDdAfTEQle5TdqQN K1lPSUw1tILuIFo4Krpgg1vq6RX5vRl774Dms4ygfl9b1uPh1FaqVgthiB7dSFdOagov OECbS2YnDySU6NZjpeU6RVc2N6YlEgnIxCKWssXFff2PJSDUpjgcR8UmzFsX+c1miO9p WhmQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=VwANrziX; 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 i4si1007806edc.580.2021.04.26.03.42.17; Mon, 26 Apr 2021 03:42:41 -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=VwANrziX; 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 S233105AbhDZKlP (ORCPT + 99 others); Mon, 26 Apr 2021 06:41:15 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:37383 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232656AbhDZKlP (ORCPT ); Mon, 26 Apr 2021 06:41:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619433633; 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=bZZsUMt0KMjKP40YJJFPdYzvGN9VTk6y13Ps6YXhbp8=; b=VwANrziXijNKq/3jslGg6lITcSbmyvOtWguwgAsq2J5p9y3SmcRAVO2UqOKYB29H8d09wV igf0795fexMx3W6Q/WAaeiPE70efyxyV51iB9d51UlWE8509UqUBiUxunecdk8X8KwLFMx X7YKSz1yktfpnKBHqcY+MBxIEbeg5iM= Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-280-Cp4z_yhXPE2ODPgvsI70Nw-1; Mon, 26 Apr 2021 06:40:32 -0400 X-MC-Unique: Cp4z_yhXPE2ODPgvsI70Nw-1 Received: by mail-ej1-f71.google.com with SMTP id ld21-20020a170906f955b029038f648a7175so353322ejb.13 for ; Mon, 26 Apr 2021 03:40:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bZZsUMt0KMjKP40YJJFPdYzvGN9VTk6y13Ps6YXhbp8=; b=gY5ziZhbELPO2NAJeLXBkzMkCtkRy5g/celtQB1B4gWpOPVDYHxzPBQjzUmIJTaWee kmJoMu+Tfmvmy3B60N2bwLoVfjXznV1OlBl/xIXKXZqU1dQr5NFv5K5EIHe6Qqocm1ap 0C2Vicqo5NuKObzbRYHHcQi8z4v6nlU1RSselh4wTnUaukUgkMEALj7Q9TaTsY8BN8mP 3p54WwTtEPXiFEwt2bi+rHAtqVniPn93rtb/zPP9tPQUvbvHrKrxptTP1/X56IoDWmcD 2hba3NKd1V7Q/012NWuOP7Q7gXzpXXSNex3RiCngSsNJ5JL1xt8MdRCQkqXeTHTFLuSB 2dDA== X-Gm-Message-State: AOAM532Zc76v9SSCp1+ywbfNkjOAUM9Kh/5EmRVQBNoGUS4JZ4KeIbDb Sz20dkCQmT2oIBjsyFbkFAdzzh8EWlHoAPbupb+ND5pzhqr9TQfBp1iYBU7sT2O1xRLfe7VN/1N BP9N+C3JmlaFIiDGJxjwl5HDy X-Received: by 2002:a05:6402:3587:: with SMTP id y7mr20979867edc.54.1619433630745; Mon, 26 Apr 2021 03:40:30 -0700 (PDT) X-Received: by 2002:a05:6402:3587:: with SMTP id y7mr20979847edc.54.1619433630557; Mon, 26 Apr 2021 03:40:30 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:5e2c:eb9a:a8b6:fd3e? ([2001:b07:6468:f312:5e2c:eb9a:a8b6:fd3e]) by smtp.gmail.com with ESMTPSA id g11sm14002799edw.37.2021.04.26.03.40.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Apr 2021 03:40:29 -0700 (PDT) Subject: Re: [PATCH v2 2/2] KVM: VMX: Invoke NMI handler via indirect call instead of INTn To: 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 References: <20200915191505.10355-1-sean.j.christopherson@intel.com> <20200915191505.10355-3-sean.j.christopherson@intel.com> From: Paolo Bonzini Message-ID: Date: Mon, 26 Apr 2021 12:40:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Paolo