LKML Archive on
help / color / mirror / Atom feed
From: Sean Christopherson <>
To: David Edmondson <>
Cc: David Matlack <>,,,
	Thomas Gleixner <>,
	Borislav Petkov <>,
	Vitaly Kuznetsov <>,
	Joerg Roedel <>, Ingo Molnar <>,
	Wanpeng Li <>,
	Jim Mattson <>,
	"H. Peter Anvin" <>,
	Paolo Bonzini <>,, Joao Martins <>
Subject: Re: [PATCH 2/2] KVM: x86: On emulation failure, convey the exit reason to userspace
Date: Fri, 9 Jul 2021 21:58:12 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Jul 02, 2021, David Edmondson wrote:
> On Wednesday, 2021-06-30 at 16:48:42 UTC, David Matlack wrote:
> > On Mon, Jun 28, 2021 at 06:31:52PM +0100, David Edmondson wrote:
> >>  	if (!is_guest_mode(vcpu) && static_call(kvm_x86_get_cpl)(vcpu) == 0) {
> >> -		vcpu->run->exit_reason = KVM_EXIT_INTERNAL_ERROR;
> >> -		vcpu->run->internal.suberror = KVM_INTERNAL_ERROR_EMULATION;
> >> -		vcpu->run->internal.ndata = 0;
> >> +		prepare_emulation_failure_exit(
> >
> > Should kvm_task_switch and kvm_handle_memory_failure also be updated
> > like this?
> Will do in v2.
> sgx_handle_emulation_failure() seems like an existing user of
> KVM_INTERNAL_ERROR_EMULATION that doesn't follow the new protocol (use
> the emulation_failure part of the union).
> Sean: If I add another flag for this case, what is the existing
> user-level consumer?

Doh, the SGX case should have been updated as part of commit c88339d88b0a ("kvm:
x86: Allow userspace to handle emulation errors").  The easiest fix for SGX would
be to zero out 'flags', bump ndata, and shift the existing field usage.  That
would resolve the existing problem of the address being misinterpreted as flags,
and would play nice _if_ additional flags are added.  I'll send a patch for that.

Regarding the consumer, there is no existing consumer per se.  SGX is simply
dumping the bad address that prevented emulation (the only SGX emulation failure
scenarios are bad/missing memslots/vmas).  The SGX case is very similar to
nested VMX instruction emulation, where failure is either due to a bad userspace
configuration (bad/missing memslot) or a busted L1 kernel (SGX instruction data
operand points at emulated MMIO).  A bad userspace configuration is almost always
going to be fatal, and I highly doubt any userspace VMM will bother emulating
SGX+MMIO.  In other words, the info dumped by SGX is purely for debug.

Which brings me back to adding another flag when dumping the exit reason.  Unless
there is a concrete use case for programmatically taking action in reponse to
failed emulation, e.g. attemping emulation in userspace using insn_bytes+insn_size,
I think we should not add a flag and instead dump info for debug/triage purposes
without committing to an ABI.  I.e. define the ABI such that KVM can dump
arbitrary info in the unused portions of data[].

Not having a true ABI will be a bit gross, but digging into these types of
failures is going to be painful no matter what; having to deduce the format of
the data is unlikely to shift the needle much.  And the code should be
straightforward, especially for userspace, e.g. dump all of data[] if emulation
in userspace failed.

  reply	other threads:[~2021-07-09 21:58 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28 17:31 [PATCH 0/2] KVM: x86: Convey the exit reason to user-space on emulation failure David Edmondson
2021-06-28 17:31 ` [PATCH 1/2] KVM: x86: Add kvm_x86_ops.get_exit_reason David Edmondson
2021-06-30 16:36   ` David Matlack
2021-06-28 17:31 ` [PATCH 2/2] KVM: x86: On emulation failure, convey the exit reason to userspace David Edmondson
2021-06-30 16:48   ` David Matlack
2021-07-02  8:44     ` David Edmondson
2021-07-09 21:58       ` Sean Christopherson [this message]
2021-07-29 13:48         ` David Edmondson
2021-06-30 16:33 ` [PATCH 0/2] KVM: x86: Convey the exit reason to user-space on emulation failure David Matlack
2021-06-30 17:08   ` David Matlack

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH 2/2] KVM: x86: On emulation failure, convey the exit reason to userspace' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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