From: Sean Christopherson <seanjc@google.com>
To: David Matlack <dmatlack@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Peter Xu <peterx@redhat.com>,
Jim Mattson <jmattson@google.com>,
Yang Zhong <yang.zhong@intel.com>,
Wei Wang <wei.w.wang@intel.com>,
Colton Lewis <coltonlewis@google.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Vipin Sharma <vipinsh@google.com>,
Aaron Lewis <aaronlewis@google.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH v3 04/10] KVM: selftests: Move flds instruction emulation failure handling to header
Date: Wed, 2 Nov 2022 19:03:34 +0000 [thread overview]
Message-ID: <Y2K/BvYwX06lsOH+@google.com> (raw)
In-Reply-To: <CALzav=eqiCbYaNUgSEsZrRGEA2pv3x5j=oUvbm=_Gho4t50H1g@mail.gmail.com>
On Wed, Nov 02, 2022, David Matlack wrote:
> On Mon, Oct 31, 2022 at 11:28 AM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Mon, Oct 31, 2022, David Matlack wrote:
> > > +
> > > +static inline void assert_exit_for_flds_emulation_failure(struct kvm_vcpu *vcpu)
> >
> > I think it makes sense to keeping the bundling of the assert+skip. As written,
> > the last test doesn't need to skip, but that may not always hold true, e.g. if
> > the test adds more stages to verify KVM handles page splits correctly, and even
> > when a skip is required, it does no harm. I can't think of a scenario where a
> > test would want an FLDS emulation error but wouldn't want to skip the instruction,
> > e.g. injecting a fault from userspace is largely an orthogonal test.
> >
> > Maybe this as a helper name? I don't think it's necessary to include "assert"
> > anywhere in the name, the idea being that "emulated" provides a hint that it's a
> > non-trivial helper.
> >
> > static inline void skip_emulated_flds(struct kvm_vcpu *vcpu)
> >
> > or skip_emulated_flds_instruction() if we're concerned that it might not be obvious
> > "flds" is an instruction mnemonic.
>
> I kept them separate for readability,
Ha, and of course I found assert_exit_for_flds_emulation_failure() hard to read :-)
> but otherwise I have no argument against bundling. I find skip_emulated*()
> somewhat misleading since flds is not actually emulated (successfully). I'm
> trending toward something like handle_flds_emulation_failure_exit() for v4.
How about "skip_flds_on_emulation_failure_exit()"? "handle" is quite generic and
doesn't provide any hints as to what the function actually does under the hood.
next prev parent reply other threads:[~2022-11-02 19:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 18:00 [PATCH v3 00/10] KVM: selftests: Fix and clean up emulator_error_test David Matlack
2022-10-31 18:00 ` [PATCH v3 01/10] KVM: selftests: Rename emulator_error_test to smaller_maxphyaddr_emulation_test David Matlack
2022-10-31 18:00 ` [PATCH v3 02/10] KVM: selftests: Explicitly require instructions bytes David Matlack
2022-10-31 18:19 ` Sean Christopherson
2022-10-31 18:00 ` [PATCH v3 03/10] KVM: selftests: Delete dead ucall code David Matlack
2022-10-31 18:19 ` Sean Christopherson
2022-10-31 18:00 ` [PATCH v3 04/10] KVM: selftests: Move flds instruction emulation failure handling to header David Matlack
2022-10-31 18:28 ` Sean Christopherson
2022-11-02 18:17 ` David Matlack
2022-11-02 19:03 ` Sean Christopherson [this message]
2022-11-02 22:02 ` David Matlack
2022-10-31 18:00 ` [PATCH v3 05/10] KVM: x86/mmu: Use BIT{,_ULL}() for PFERR masks David Matlack
2022-10-31 18:00 ` [PATCH v3 06/10] KVM: selftests: Copy KVM PFERR masks into selftests David Matlack
2022-10-31 18:28 ` Sean Christopherson
2022-10-31 18:00 ` [PATCH v3 07/10] KVM: selftests: Avoid JMP in non-faulting path of KVM_ASM_SAFE() David Matlack
2022-10-31 18:00 ` [PATCH v3 08/10] KVM: selftests: Provide error code as a KVM_ASM_SAFE() output David Matlack
2022-10-31 18:00 ` [PATCH v3 09/10] KVM: selftests: Expect #PF(RSVD) when TDP is disabled David Matlack
2022-10-31 18:07 ` Sean Christopherson
2022-10-31 18:00 ` [PATCH v3 10/10] KVM: selftests: Add a test for KVM_CAP_EXIT_ON_EMULATION_FAILURE David Matlack
2022-10-31 18:37 ` 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=Y2K/BvYwX06lsOH+@google.com \
--to=seanjc@google.com \
--cc=aaronlewis@google.com \
--cc=coltonlewis@google.com \
--cc=dmatlack@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=vipinsh@google.com \
--cc=vkuznets@redhat.com \
--cc=wei.w.wang@intel.com \
--cc=yang.zhong@intel.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