On Thu, Jan 23, 2020 at 10:22:24AM -0800, Jim Mattson wrote: > On Thu, Jan 23, 2020 at 1:54 AM Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > > On 23/01/20 10:45, Vitaly Kuznetsov wrote: > > >>> SDM says that "If an > > >>> unsupported INVVPID type is specified, the instruction fails." and this > > >>> is similar to INVEPT and I decided to check what handle_invept() > > >>> does. Well, it does BUG_ON(). > > >>> > > >>> Are we doing the right thing in any of these cases? > > >> > > >> Yes, both INVEPT and INVVPID catch this earlier. > > >> > > >> So I'm leaning towards not applying Miaohe's patch. > > > > > > Well, we may at least want to converge on BUG_ON() for both > > > handle_invvpid()/handle_invept(), there's no need for them to differ. > > > > WARN_ON_ONCE + nested_vmx_failValid would probably be better, if we > > really want to change this. > > > > Paolo > > In both cases, something is seriously wrong. The only plausible > explanations are compiler error or hardware failure. It would be nice > to handle *all* such failures with a KVM_INTERNAL_ERROR exit to > userspace. (I'm also thinking of situations like getting a VM-exit for > INIT.) Ya. Vitaly and I had a similar discussion[*]. The idea we tossed around was to also mark the VM as having encountered a KVM/hardware bug so that the VM is effectively dead. That would also allow gracefully handling bugs that are detected deep in the stack, i.e. can't simply return 0 to get out to userspace. [*] https://lkml.kernel.org/r/20190930153358.GD14693@xxxxxxxxxxxxxxx
