[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240123203853.66655e95@rorschach.local.home>
Date: Tue, 23 Jan 2024 20:38:53 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: "Naik, Avadhut" <avadnaik@....com>
Cc: Tony Luck <tony.luck@...el.com>, Avadhut Naik <avadhut.naik@....com>,
linux-trace-kernel@...r.kernel.org, linux-edac@...r.kernel.org,
bp@...en8.de, x86@...nel.org, linux-kernel@...r.kernel.org,
yazen.ghannam@....com
Subject: Re: [PATCH] tracing: Include PPIN in mce_record tracepoint
On Tue, 23 Jan 2024 19:29:52 -0600
"Naik, Avadhut" <avadnaik@....com> wrote:
> > But some questions:
> >
> > 1) Are tracepoints a user visible ABI? Adding a new field in the middle
> > feels like it might be problematic. I asked this question many years
> > ago and Steven Rostedt said there was some tracing library in the works
> > that would make this OK for appplications using that library.
> >
>
> I think they can be user visible through the "trace" and "trace_pipe" in
> /sys/kernel/debug/tracing. But you will have to enable the events you want
> to trace through /sys/kernel/debug/tracing/events/<event-name>/enable.
>
> AFAIK, this (adding field in the middle) shouldn't be problematic as we
> have the tracepoint format available in debugfs. For e.g. with this patch,
> the format is as follows:
>
> [root avadnaik]# cat /sys/kernel/debug/tracing/events/mce/mce_record/format
> name: mce_record
> ID: 113
> format:
> field:unsigned short common_type; offset:0; size:2; signed:0;
> field:unsigned char common_flags; offset:2; size:1; signed:0;
> field:unsigned char common_preempt_count; offset:3; size:1; signed:0;
> field:int common_pid; offset:4; size:4; signed:1;
>
> field:u64 mcgcap; offset:8; size:8; signed:0;
> field:u64 mcgstatus; offset:16; size:8; signed:0;
> field:u64 status; offset:24; size:8; signed:0;
> field:u64 addr; offset:32; size:8; signed:0;
> field:u64 misc; offset:40; size:8; signed:0;
> field:u64 synd; offset:48; size:8; signed:0;
> field:u64 ipid; offset:56; size:8; signed:0;
> field:u64 ip; offset:64; size:8; signed:0;
> field:u64 tsc; offset:72; size:8; signed:0;
> field:u64 ppin; offset:80; size:8; signed:0;
> field:u64 walltime; offset:88; size:8; signed:0;
> field:u32 cpu; offset:96; size:4; signed:0;
> field:u32 cpuid; offset:100; size:4; signed:0;
> field:u32 apicid; offset:104; size:4; signed:0;
> field:u32 socketid; offset:108; size:4; signed:0;
> field:u8 cs; offset:112; size:1; signed:0;
> field:u8 bank; offset:113; size:1; signed:0;
> field:u8 cpuvendor; offset:114; size:1; signed:0;
>
> print fmt: "CPU: %d, MCGc/s: %llx/%llx, MC%d: %016Lx, IPID: %016Lx, ADDR/MISC/SYND: %016Lx/%016Lx/%016Lx, RIP: %02x:<%016Lx>, TSC: %llx, PPIN: %llx, PROCESSOR: %u:%x, TIME: %llu, SOCKET: %u, APIC: %x", REC->cpu, REC->mcgcap, REC->mcgstatus, REC->bank, REC->status, REC->ipid, REC->addr, REC->misc, REC->synd, REC->cs, REC->ip, REC->tsc, REC->ppin, REC->cpuvendor, REC->cpuid, REC->walltime, REC->socketid, REC->apicid
>
>
> Just quickly tried with rasdaemon and things seem to be okay.
>
> Also, not a cent percent sure, but the library you are mentioning of, I think
> its the libtraceevent library and IIUC, it utilizes the above tracepoint format.
>
Yes, rasdaemon uses libtraceevent (or a copy of it internally) that
reads the format file to find fields. You can safely add fields to the
middle of the event structure and the parsing will be just fine.
-- Steve
Powered by blists - more mailing lists