linux-kernel - Re: [PATCH 6/7] KVM: x86: Use common definition for kvm_nested

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200721193130.GH22083@linux.intel.com>
Date:   Tue, 21 Jul 2020 12:31:30 -0700
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>
Cc:     Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH 6/7] KVM: x86: Use common definition for
 kvm_nested_vmexit tracepoint

+Steve

Background: KVM has two tracepoints that effectively trace the same thing
(VM-Exit vs. nested VM-Exit), but use completely different formatting and
nomenclature for each of the existing tracepoints.  I want to add a common
macro to create the tracepoints so that they capture the exact same info
and report it with the exact same format.  But that means breaking the
"ABI" for one of the tracepoints, e.g. trace-cmd barfs on the rename of
exit_code to exit_reason.

Was there ever a verdict on whether or not tracepoints are considered ABI
and thus must retain backwards compatibility?

If not, what's the proper way to upstream changes to trace-cmd?

Thanks!

On Tue, Jul 21, 2020 at 03:59:06PM +0200, Vitaly Kuznetsov wrote:
> Sean Christopherson <sean.j.christopherson@...el.com> writes:
> >> Sean Christopherson <sean.j.christopherson@...el.com> writes:
> >> With so many lines removed I'm almost in love with the patch! However,
> >> when testing on SVM (unrelated?) my trace log looks a bit ugly:
> >> 
> >>            <...>-315119 [010]  3733.092646: kvm_nested_vmexit:    CAN'T FIND FIELD "rip"<CANT FIND FIELD exit_code>vcpu 0 reason npf rip 0x400433 info1 0x0000000200000006 info2 0x0000000000641000 intr_info 0x00000000 error_code 0x00000000
> >>            <...>-315119 [010]  3733.092655: kvm_nested_vmexit:    CAN'T FIND FIELD "rip"<CANT FIND FIELD exit_code>vcpu 0 reason npf rip 0x400433 info1 0x0000000100000014 info2 0x0000000000400000 intr_info 0x00000000 error_code 0x00000000
> >> 
> >> ...
> >> 
> >> but after staring at this for some time I still don't see where this
> >> comes from :-( ... but reverting this commit helps:
> >
> > The CAN'T FIND FIELD blurb comes from tools/lib/traceevent/event-parse.c.
> >
> > I assume you are using tooling of some form to generate the trace, i.e. the
> > issue doesn't show up in /sys/kernel/debug/tracing/trace.  If that's the
> > case, this is more or less ABI breakage :-(
> >  
> 
> Right you are,
> 
> the tool is called 'trace-cmd record -e kvm ...' / 'trace-cmd report'
> but I always thought it's not any different from looking at
> /sys/kernel/debug/tracing/trace directly. Apparently I was wrong. 'cat
> /sys/kernel/debug/tracing/trace' seems to be OK, e.g.:
> 
>  qemu-system-x86-20263 [006] .... 75982.292657: kvm_nested_vmexit: vcpu 0 reason hypercall rip 0x40122f info1 0x0000000000000000 info2 0x0000000000000000 intr_info 0x00000000 error_code 0x00000000
> 
> -- 
> Vitaly
>