All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Tao Xu <tao3.xu@intel.com>
Cc: x86@kernel.org, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, Xiaoyao Li <xiaoyao.li@intel.com>,
	pbonzini@redhat.com, seanjc@google.com, wanpengli@tencent.com,
	jmattson@google.com, joro@8bytes.org, tglx@linutronix.de,
	mingo@redhat.com, bp@alien8.de, hpa@zytor.com
Subject: Re: [PATCH v2] KVM: VMX: Enable Notify VM exit
Date: Thu, 03 Jun 2021 15:43:17 +0200	[thread overview]
Message-ID: <87im2v12tm.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <12db5b88-a094-4fb0-eeac-e79396009f44@intel.com>

Tao Xu <tao3.xu@intel.com> writes:

> On 6/2/21 6:31 PM, Vitaly Kuznetsov wrote:
>> Tao Xu <tao3.xu@intel.com> writes:
>> 
>>> There are some cases that malicious virtual machines can cause CPU stuck
>>> (event windows don't open up), e.g., infinite loop in microcode when
>>> nested #AC (CVE-2015-5307). No event window obviously means no events,
>>> e.g. NMIs, SMIs, and IRQs will all be blocked, may cause the related
>>> hardware CPU can't be used by host or other VM.
>>>
>>> To resolve those cases, it can enable a notify VM exit if no event
>>> window occur in VMX non-root mode for a specified amount of time
>>> (notify window). Since CPU is first observed the risk of not causing
>>> forward progress, after notify window time in a units of crystal clock,
>>> Notify VM exit will happen. Notify VM exit can happen incident to delivery
>>> of a vectored event.
>>>
>>> Expose a module param for configuring notify window, which is in unit of
>>> crystal clock cycle.
>>> - A negative value (e.g. -1) is to disable this feature.
>>> - Make the default as 0. It is safe because an internal threshold is added
>>> to notify window to ensure all the normal instructions being coverd.
>>> - User can set it to a large value when they want to give more cycles to
>>> wait for some reasons, e.g., silicon wrongly kill some normal instruction
>>> due to internal threshold is too small.
>>>
>>> Notify VM exit is defined in latest Intel Architecture Instruction Set
>>> Extensions Programming Reference, chapter 9.2.
>>>
>>> Co-developed-by: Xiaoyao Li <xiaoyao.li@intel.com>
>>> Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
>>> Signed-off-by: Tao Xu <tao3.xu@intel.com>
>>> ---
>>>
>>> Changelog:
>>> v2:
>>>       Default set notify window to 0, less than 0 to disable.
>>>       Add more description in commit message.
>> 
>> Sorry if this was already discussed, but in case of nested
>> virtualization and when L1 also enables
>> SECONDARY_EXEC_NOTIFY_VM_EXITING, shouldn't we just reflect NOTIFY exits
>> during L2 execution to L1 instead of crashing the whole L1?
>> 
> Notify VM Exit will not crash L1 guest if VM context valid in exit 
> qualification. After VM exit, VMM can resume the guest normally.

Wrong choice of words, sorry. Indeed, VMM is free to decide what to do
upon such vmexit.

-- 
Vitaly


  reply	other threads:[~2021-06-03 13:43 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25  5:12 [PATCH v2] KVM: VMX: Enable Notify VM exit Tao Xu
2021-06-02 10:31 ` Vitaly Kuznetsov
2021-06-03  1:23   ` Tao Xu
2021-06-03 13:43     ` Vitaly Kuznetsov [this message]
2021-06-03  1:25   ` Xiaoyao Li
2021-06-03 13:35     ` Jim Mattson
2021-06-07  9:24       ` Xiaoyao Li
2021-06-03 13:52     ` Vitaly Kuznetsov
2021-06-07  9:23       ` Xiaoyao Li
2021-06-24  4:52 ` Tao Xu
2021-07-22  3:25 ` Xiaoyao Li
2021-07-30 20:41 ` Sean Christopherson
2021-08-02 12:53   ` Xiaoyao Li
2021-08-02 15:46     ` Sean Christopherson
2021-08-03  0:38       ` Xiaoyao Li
2021-09-02  9:28         ` Chenyi Qiang
2021-09-02 16:29           ` Sean Christopherson
2021-09-07 13:33             ` Xiaoyao Li
2021-09-09 18:47               ` Sean Christopherson
2021-09-10  7:39                 ` Xiaoyao Li
2021-09-10 17:55                   ` Sean Christopherson
2021-09-02 16:15         ` Sean Christopherson
2021-09-02 16:36           ` Sean Christopherson
2021-09-07 13:45             ` Xiaoyao Li
2021-09-09 18:59               ` Sean Christopherson
2021-09-13  2:58                 ` Xiaoyao Li
2021-10-15 18:29                   ` Sean Christopherson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87im2v12tm.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=tao3.xu@intel.com \
    --cc=tglx@linutronix.de \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    --cc=xiaoyao.li@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.