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;
Message-ID: <88eb9a9a-fbe3-8e2c-02bd-4bdfc855b67f@intel.com>
Date:   Fri, 25 Feb 2022 23:04:46 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.6.1
Subject: Re: [PATCH v3] KVM: VMX: Enable Notify VM exit
Content-Language: en-US
To:     Jim Mattson <jmattson@google.com>,
        Chenyi Qiang <chenyi.qiang@intel.com>
Cc:     Paolo Bonzini <pbonzini@redhat.com>,
        Sean Christopherson <seanjc@google.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Joerg Roedel <joro@8bytes.org>, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20220223062412.22334-1-chenyi.qiang@intel.com>
 <CALMp9eT50LjXYSwfWENjmfg=XxT4Bx3RzOYubKty8kr_APXCEw@mail.gmail.com>
From:   Xiaoyao Li <xiaoyao.li@intel.com>
In-Reply-To: <CALMp9eT50LjXYSwfWENjmfg=XxT4Bx3RzOYubKty8kr_APXCEw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 2/25/2022 10:54 PM, Jim Mattson wrote:
> On Tue, Feb 22, 2022 at 10:19 PM Chenyi Qiang <chenyi.qiang@intel.com> wrote:
>>
>> From: Tao Xu <tao3.xu@intel.com>
>>
>> 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?

For now, no case will set VM_CONTEXT_INVALID bit.

In the future, it must be some fatal case that vmcs is corrupted.

>> 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.

Then, maybe a dedicated software define VM exit for it instead of 
reusing triple fault?