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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DEDA4C433EF for ; Fri, 25 Feb 2022 14:55:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242135AbiBYO4I (ORCPT ); Fri, 25 Feb 2022 09:56:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45278 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242049AbiBYOzq (ORCPT ); Fri, 25 Feb 2022 09:55:46 -0500 Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7B0A5BE74 for ; Fri, 25 Feb 2022 06:55:02 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id k2so7705349oia.2 for ; Fri, 25 Feb 2022 06:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fT9I2+VK56i3wPL86YtJ9oujG8H0O8fU0cHW61eJ+nI=; b=ocDI0bpFAlfLlz07Ms9K+Es333B3xLcQsKts2hKdJZcyNuG3hdXqwFx9uzp6xJx/OJ VFtkctoftImw0HiMt6IABpjV9KFsNuRi2IMqlb/L+zOrBJB6+X4dfnGQVSt2ji7qzpVT twWwoDZbKmWF0Y/UJWgNgp1mIty0Vee1wKPGbg9SYDIS38MO+4e6FUC4kkiFPiRaBOO9 A/kyypO6Xa0o9Hu7Xnqr7z7e+EEiETdYvryFdK1l/kAFrxq6cCKRERuY2NBRA/mRg8Ov s/X0nsQejkjtXdm0XCUKrLjZdoOc2qZfqFvW7Voj+fX2rrr9k1X4RvRWrra3Zo8c0WBd DtSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fT9I2+VK56i3wPL86YtJ9oujG8H0O8fU0cHW61eJ+nI=; b=eoQ0eZ/ZYjCXt7Fdtv+rQfjhpZ/k2hcl3yFg8QjZMxdsTbbvDZN9JKjl7bjJggeAUv 46qsv9WHF3wBsW9avWuvSlzXbp/4iqlJgKmUlkjvi4pq40ZHxXHo7l4VaMZjW8WhZZgp TKTYzQJDt+K919MiszMiZIlTLQMamDJtcduC3ja7byqRD09jqatNDYhIEN+Zx1wuj5Uq wVu5H978zScumUoNydOf4sZOJGT49hY8s2x3v5EOcnsVlFrMHg7gK1++GeCN9FiGQ2Ov csT/wkWsNF/kOhBbBmuybS90lLb7dzOXb2FTeJuniHJxQrUgkK4TB7RyPS+slMkfooOW GzMQ== X-Gm-Message-State: AOAM533dShnKWhmbsgt4H9rsIRTRxRRW+xzie6l6EaO3HfhBHvqIFDmO wEutm8LG5nZ6d2+FBSOeP4RVdxrJWQv1tGPyHHjVTA== X-Google-Smtp-Source: ABdhPJyM/iJYLsnWoSrKflbZP2N/fNnclFQmE8TzasWzLZmG6Q5uy9uh18fJ4PKpZNI4faItAjnGa6ceCrKGO94B7ug= X-Received: by 2002:a05:6808:23d0:b0:2d6:bca2:c70 with SMTP id bq16-20020a05680823d000b002d6bca20c70mr1755978oib.339.1645800901850; Fri, 25 Feb 2022 06:55:01 -0800 (PST) MIME-Version: 1.0 References: <20220223062412.22334-1-chenyi.qiang@intel.com> In-Reply-To: <20220223062412.22334-1-chenyi.qiang@intel.com> From: Jim Mattson Date: Fri, 25 Feb 2022 06:54:50 -0800 Message-ID: Subject: Re: [PATCH v3] KVM: VMX: Enable Notify VM exit To: Chenyi Qiang Cc: Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Joerg Roedel , Xiaoyao Li , Tao Xu , kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 22, 2022 at 10:19 PM Chenyi Qiang wrote: > > From: Tao Xu > > There are cases that malicious virtual machines can cause CPU stuck (due > to event windows don't open up), e.g., infinite loop in microcode when > nested #AC (CVE-2015-5307). No event window means no event (NMI, SMI and > IRQ) can be delivered. It leads the CPU to be unavailable to host or > other VMs. > > VMM can enable notify VM exit that a VM exit generated if no event > window occurs in VM non-root mode for a specified amount of time (notify > window). > > Feature enabling: > - The new vmcs field SECONDARY_EXEC_NOTIFY_VM_EXITING is introduced to > enable this feature. VMM can set NOTIFY_WINDOW vmcs field to adjust > the expected notify window. > - Expose a module param to configure notify window by admin, which is in > unit of crystal clock. > - if notify_window < 0, feature disabled; > - if notify_window >= 0, feature enabled; > - There's a possibility, however small, that a notify VM exit happens > with VM_CONTEXT_INVALID set in exit qualification. In this case, the > vcpu can no longer run. To avoid killing a well-behaved guest, set > notify window as -1 to disable this feature by default. > - It's safe to even set notify window to zero since an internal > hardware threshold is added to vmcs.notifiy_window. What causes a VM_CONTEXT_INVALID VM-exit? How small is this possibility? > Nested handling > - Nested notify VM exits are not supported yet. Keep the same notify > window control in vmcs02 as vmcs01, so that L1 can't escape the > restriction of notify VM exits through launching L2 VM. > - When L2 VM is context invalid, synthesize a nested > EXIT_REASON_TRIPLE_FAULT to L1 so that L1 won't be killed due to L2's > VM_CONTEXT_INVALID happens. I don't like the idea of making things up without notifying userspace that this is fictional. How is my customer running nested VMs supposed to know that L2 didn't actually shutdown, but L0 killed it because the notify window was exceeded? If this information isn't reported to userspace, I have no way of getting the information to the customer.