From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B78C2C433B4 for ; Mon, 26 Apr 2021 10:40:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7A2DC611CE for ; Mon, 26 Apr 2021 10:40:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233110AbhDZKlQ (ORCPT ); Mon, 26 Apr 2021 06:41:16 -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-Google-Smtp-Source: ABdhPJzUlQIAYodwBzUUiJWgYEpzQujF933VDY95XxUTEaag8DV7wjbNaWtxum0gxZnhcW6tOwzmwg== 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