On Mon, Mar 11, 2019 at 02:42:06PM -0700, Jim Mattson wrote:
> On Fri, Mar 8, 2019 at 3:16 PM Sean Christopherson
> <sean.j.christopherson@xxxxxxxxx> wrote:
> >
> > Use the recently added tracepoint for logging nested VM-Enter failures
> > instead of spamming the kernel log when hardware detects a consistency
> > check failure. Take the opportunity to print the name of the error code
> > instead of dumping the raw hex number, but limit the symbol table to
> > error codes that can reasonably be encountered by KVM.
> >
> > Add an equivalent tracepoint in nested_vmx_check_vmentry_hw() so that
> > "invalid control field" errors aren't suppressed when nested early
> > checks are enabled.
> >
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
...
> > @@ -5061,8 +5064,9 @@ bool nested_vmx_exit_reflected(struct kvm_vcpu *vcpu, u32 exit_reason)
> > return false;
> >
> > if (unlikely(vmx->fail)) {
> > - pr_info_ratelimited("%s failed vm entry %x\n", __func__,
> > - vmcs_read32(VM_INSTRUCTION_ERROR));
>
> I *love* the tracing, but I don't think we want to turn it on for
> production. Can we keep the pr_info_ratelimited for when tracing is
> disabled?
Could we drop it to pr_debug_ratelimited()? Say "no" if it's at all
inconvenient to use debug instead of info. The printing is nothing
more than a minor annoyance when I'm running unit tests, i.e. any kind
of actual use case trumps my partiality for a clean kernel log.
>
> > + trace_kvm_nested_vmenter_failed(
> > + "hardware VM-instruction error: ",
> > + vmcs_read32(VM_INSTRUCTION_ERROR));
> > return true;
> > }
> >
> > --
> > 2.21.0
> >
