All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>,
	Alexander Graf <graf@amazon.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
	"Vitaly Kuznetsov" <vkuznets@redhat.com>,
	"Wanpeng Li" <wanpengli@tencent.com>,
	"Jim Mattson" <jmattson@google.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Liran Alon" <liran.alon@oracle.com>
Subject: Re: [PATCH v2 00/14] KVM: x86: Remove emulation_result enums
Date: Wed, 6 Nov 2019 13:17:40 +0100	[thread overview]
Message-ID: <3d827e8b-a04e-0a93-4bb4-e0e9d59036da@redhat.com> (raw)
In-Reply-To: <20191106005806.GK23297@linux.intel.com>

On 06/11/19 01:58, Sean Christopherson wrote:
>> enum kvm_return {
>>     KVM_RET_USER_EXIT = 0,
>>     KVM_RET_GUEST = 1,
>> };
>>
>> and then consistently use them as return values? That way anyone who has not
>> worked on kvm before can still make sense of the code.
> Hmm, I think it'd make more sense to use #define instead of enum to
> hopefully make it clear that they aren't the *only* values that can be
> returned.  That'd also prevent anyone from changing the return types from
> 'int' to 'enum kvm_return', which IMO would hurt readability overall.
> 
> And maybe KVM_EXIT_TO_USERSPACE and KVM_RETURN_TO_GUEST?

That would be quite some work.  Right now there is some consistency
between all of:

- x86_emulate_instruction and its callers

- vcpu->arch.complete_userspace_io

- vcpu_enter_guest/vcpu_block

- kvm_x86_ops->handle_exit

so it would be very easy to end up with a half-int-half-enum state that
is more confusing than before...

I'm more worried about cases where we have functions returning either 0
or -errno, but 0 lets you enter the guest.  I'm not sure if the only one
is kvm_mmu_reload or there are others.

Paolo

  reply	other threads:[~2019-11-06 12:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-27 21:40 [PATCH v2 00/14] KVM: x86: Remove emulation_result enums Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 01/14] KVM: x86: Relocate MMIO exit stats counting Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 02/14] KVM: x86: Clean up handle_emulation_failure() Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 03/14] KVM: x86: Refactor kvm_vcpu_do_singlestep() to remove out param Sean Christopherson
2019-09-17 15:07   ` Paolo Bonzini
2019-08-27 21:40 ` [PATCH v2 04/14] KVM: x86: Don't attempt VMWare emulation on #GP with non-zero error code Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 05/14] KVM: x86: Move #GP injection for VMware into x86_emulate_instruction() Sean Christopherson
2019-08-27 22:03   ` Liran Alon
2019-08-27 21:40 ` [PATCH v2 06/14] KVM: x86: Add explicit flag for forced emulation on #UD Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 07/14] KVM: x86: Move #UD injection for failed emulation into emulation code Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 08/14] KVM: x86: Exit to userspace on emulation skip failure Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 09/14] KVM: x86: Handle emulation failure directly in kvm_task_switch() Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 10/14] KVM: x86: Move triple fault request into RM int injection Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 11/14] KVM: VMX: Remove EMULATE_FAIL handling in handle_invalid_guest_state() Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 12/14] KVM: x86: Remove emulation_result enums, EMULATE_{DONE,FAIL,USER_EXIT} Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 13/14] KVM: VMX: Handle single-step #DB for EMULTYPE_SKIP on EPT misconfig Sean Christopherson
2019-08-27 21:40 ` [PATCH v2 14/14] KVM: x86: Add comments to document various emulation types Sean Christopherson
2019-09-17 15:14 ` [PATCH v2 00/14] KVM: x86: Remove emulation_result enums Paolo Bonzini
2019-10-25 11:00   ` Alexander Graf
2019-11-06  0:58     ` Sean Christopherson
2019-11-06 12:17       ` Paolo Bonzini [this message]
2019-11-06 22:27         ` 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=3d827e8b-a04e-0a93-4bb4-e0e9d59036da@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=graf@amazon.com \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liran.alon@oracle.com \
    --cc=rkrcmar@redhat.com \
    --cc=sean.j.christopherson@intel.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.