From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Jim Mattson <jmattson@google.com>,
Chenyi Qiang <chenyi.qiang@intel.com>
Cc: 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
Subject: Re: [PATCH v3] KVM: VMX: Enable Notify VM exit
Date: Sat, 26 Feb 2022 12:07:25 +0800 [thread overview]
Message-ID: <bcc83b3d-31fe-949a-6bbf-4615bb982f0c@intel.com> (raw)
In-Reply-To: <7859e03f-10fa-dbc2-ed3c-5c09e62f9016@redhat.com>
On 2/25/2022 11:13 PM, Paolo Bonzini wrote:
> On 2/25/22 16:12, Xiaoyao Li wrote:
>>>>>
>>>>
>>>> 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?
>>>
>>
>> Second thought, we can even just return Notify VM exit to L1 to tell
>> L2 causes Notify VM exit, even thought Notify VM exit is not exposed
>> to L1.
>
> That might cause NULL pointer dereferences or other nasty occurrences.
IMO, a well written VMM (in L1) should handle it correctly.
L0 KVM reports no Notify VM Exit support to L1, so L1 runs without
setting Notify VM exit. If a L2 causes notify_vm_exit with
invalid_vm_context, L0 just reflects it to L1. In L1's view, there is no
support of Notify VM Exit from VMX MSR capability. Following L1 handler
is possible:
a) if (notify_vm_exit available & notify_vm_exit enabled) {
handle in b)
} else {
report unexpected vm exit reason to userspace;
}
b) similar handler like we implement in KVM:
if (!vm_context_invalid)
re-enter guest;
else
report to userspace;
c) no Notify VM Exit related code (e.g. old KVM), it's treated as
unsupported exit reason
As long as it belongs to any case above, I think L1 can handle it
correctly. Any nasty occurrence should be caused by incorrect handler in
L1 VMM, in my opinion.
> Paolo
>
next prev parent reply other threads:[~2022-02-26 4:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 6:24 [PATCH v3] KVM: VMX: Enable Notify VM exit Chenyi Qiang
2022-02-25 11:54 ` Paolo Bonzini
2022-02-25 12:46 ` Xiaoyao Li
2022-02-25 14:54 ` Jim Mattson
2022-02-25 15:04 ` Xiaoyao Li
2022-02-25 15:12 ` Xiaoyao Li
2022-02-25 15:13 ` Paolo Bonzini
2022-02-25 18:06 ` Jim Mattson
2022-02-25 18:29 ` Sean Christopherson
2022-02-25 19:15 ` Jim Mattson
2022-02-26 4:07 ` Xiaoyao Li [this message]
2022-02-26 4:25 ` Jim Mattson
2022-02-26 4:53 ` Jim Mattson
2022-02-26 6:24 ` Xiaoyao Li
2022-02-26 14:24 ` Jim Mattson
2022-02-28 7:10 ` Xiaoyao Li
2022-02-28 14:30 ` Jim Mattson
2022-03-01 1:40 ` Xiaoyao Li
2022-03-01 4:32 ` Jim Mattson
2022-03-01 5:30 ` Xiaoyao Li
2022-03-01 21:57 ` Jim Mattson
2022-03-02 2:15 ` Chenyi Qiang
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=bcc83b3d-31fe-949a-6bbf-4615bb982f0c@intel.com \
--to=xiaoyao.li@intel.com \
--cc=chenyi.qiang@intel.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox