From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] KVM: nVMX: Properly handle kvm_read/write_guest_virt*() result
Date: Fri, 5 Jun 2020 13:06:51 -0700 [thread overview]
Message-ID: <20200605200651.GC11449@linux.intel.com> (raw)
In-Reply-To: <20200605115906.532682-1-vkuznets@redhat.com>
On Fri, Jun 05, 2020 at 01:59:05PM +0200, Vitaly Kuznetsov wrote:
> Introduce vmx_handle_memory_failure() as an interim solution.
Heh, "interim". I'll take the over on that :-D.
> Note, nested_vmx_get_vmptr() now has three possible outcomes: OK, PF,
> KVM_EXIT_INTERNAL_ERROR and callers need to know if userspace exit is
> needed (for KVM_EXIT_INTERNAL_ERROR) in case of failure. We don't seem
> to have a good enum describing this tristate, just add "int *ret" to
> nested_vmx_get_vmptr() interface to pass the information.
>
> Reported-by: syzbot+2a7156e11dc199bdbd8a@syzkaller.appspotmail.com
> Suggested-by: Sean Christopherson <sean.j.christopherson@intel.com>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
...
> +/*
> + * Handles kvm_read/write_guest_virt*() result and either injects #PF or returns
> + * KVM_EXIT_INTERNAL_ERROR for cases not currently handled by KVM. Return value
> + * indicates whether exit to userspace is needed.
> + */
> +int vmx_handle_memory_failure(struct kvm_vcpu *vcpu, int r,
> + struct x86_exception *e)
> +{
> + if (r == X86EMUL_PROPAGATE_FAULT) {
> + kvm_inject_emulated_page_fault(vcpu, e);
> + return 1;
> + }
> +
> + /*
> + * In case kvm_read/write_guest_virt*() failed with X86EMUL_IO_NEEDED
> + * while handling a VMX instruction KVM could've handled the request
A nit similar to your observation on the shortlog, this isn't limited to VMX
instructions.
> + * correctly by exiting to userspace and performing I/O but there
> + * doesn't seem to be a real use-case behind such requests, just return
> + * KVM_EXIT_INTERNAL_ERROR for now.
> + */
> + vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
> + vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION;
> + vcpu->run->internal.ndata = 0;
> +
> + return 0;
> +}
next prev parent reply other threads:[~2020-06-05 20:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-05 11:59 [PATCH v2 1/2] KVM: nVMX: Properly handle kvm_read/write_guest_virt*() result Vitaly Kuznetsov
2020-06-05 11:59 ` [PATCH v2 2/2] Revert "KVM: x86: work around leak of uninitialized stack contents" Vitaly Kuznetsov
2020-06-05 17:33 ` Paolo Bonzini
2020-06-05 12:01 ` [PATCH v2 1/2] KVM: nVMX: Properly handle kvm_read/write_guest_virt*() result Vitaly Kuznetsov
2020-06-05 20:06 ` Sean Christopherson [this message]
2020-06-08 8:20 ` Vitaly Kuznetsov
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=20200605200651.GC11449@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.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 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.