All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.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: Mon, 08 Jun 2020 10:20:44 +0200	[thread overview]
Message-ID: <878sgyc6jn.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <20200605200651.GC11449@linux.intel.com>

Sean Christopherson <sean.j.christopherson@intel.com> writes:

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

We just need a crazy but real use-case to start acting :-)

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

On a loosely related note, while writing this patch I was struggling
with our exit handlers calling convention (that the return value is '1'
- return to the guest, '0' - return to userspace successfully, '< 0' -
return to userspace with an error). This is intertwined with normal
int/bool functions and make it hard to read. At the very minimum we can
introduce an enum for 0/1 return values from exit handlers. Or, maybe,
we can introduce KVM_REQ_USERSPACE_EXIT/KVM_REQ_INTERNAL_ERROR/.. and
make all the exit handlers normal functions returning 0/error?

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

Yea, it all started with nested_vmx_get_vmptr() then Paolo discovered
vmwrite/vmread/vmptrst/invept/invvpid and then I discovered invpcid but
forgot to update the comment ...

>> +	 * 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;
>> +}
>

-- 
Vitaly


      reply	other threads:[~2020-06-08  8:20 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
2020-06-08  8:20   ` Vitaly Kuznetsov [this message]

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=878sgyc6jn.fsf@vitty.brq.redhat.com \
    --to=vkuznets@redhat.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=sean.j.christopherson@intel.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.