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(
> >> + vcpu, KVM_INTERNAL_ERROR_EMULATION_FLAG_EXIT_REASON);
> >
> > 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.
