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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).