From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1754305Ab3KYNin (ORCPT <rfc822;w@1wt.eu>);
	Mon, 25 Nov 2013 08:38:43 -0500
Received: from mx1.redhat.com ([209.132.183.28]:30039 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754158Ab3KYNim (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 25 Nov 2013 08:38:42 -0500
Date: Mon, 25 Nov 2013 14:38:06 +0100
From: Jiri Olsa <jolsa@redhat.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: linux-kernel@vger.kernel.org, Corey Ashford <cjashfor@linux.vnet.ibm.com>,
        Frederic Weisbecker <fweisbec@gmail.com>, Ingo Molnar <mingo@elte.hu>,
        Paul Mackerras <paulus@samba.org>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        Arnaldo Carvalho de Melo <acme@redhat.com>,
        Steven Rostedt <rostedt@goodmis.org>, David Ahern <dsahern@gmail.com>,
        Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: Re: [PATCH 11/22] tools lib traceevent: Add xen plugin
Message-ID: <20131125133806.GF3161@krava.brq.redhat.com>
References: <1385031680-9014-1-git-send-email-jolsa@redhat.com>
 <1385031680-9014-12-git-send-email-jolsa@redhat.com>
 <1385132788.1747.70.camel@leonhard>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1385132788.1747.70.camel@leonhard>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, Nov 23, 2013 at 12:06:28AM +0900, Namhyung Kim wrote:
> 2013-11-21 (목), 12:01 +0100, Jiri Olsa:
> > Adding xen plugin.
> > 
> > This plugin adds fields resolving for
> > following tracepoint events:
> >   xen:xen_mc_entry
> >   xen:xen_mc_extend_args
> > 
> > The diff of 'perf script' output generated by old and new code:
> > (data was generated by 'perf record -e 'xen:*' ls')
> > 
> > --- script.xen.old
> > +++ script.xen.new
> > -         swapper     0 [002]   136.267492: xen:xen_mc_entry: [FAILED TO PARSE] op=3 nargs=2 args=ARRAY[18, 00, 00, 00, 00, 00, 00, 00, 00, e0, d4, 4b, 04, 88, ff, ff, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00]
> > +         swapper     0 [002]   136.267492: xen:xen_mc_entry: op 3(stack_switch) args [18, 0, 0, 0, 0, 0]
> > -            perf  1970 [008]   136.273319: xen:xen_mc_extend_args: [FAILED TO PARSE] op=1 args=16 res=1
> > +            perf  1970 [008]   136.273319: xen:xen_mc_extend_args: extending op 1(mmu_update) by 16 bytes res ???
> > 
> > NOTE We still do not handle the 'sizeof' and fail
> > to parse following xen tracepoints:
> >   xen:xen_mmu_set_pte
> >   xen:xen_mmu_set_pte_atomic
> >   xen:xen_mmu_set_domain_pte
> >   xen:xen_mmu_set_pte_at
> >   xen:xen_mmu_set_pmd
> >   xen:xen_mmu_set_pud
> >   xen:xen_mmu_set_pgd
> >   xen:xen_mmu_ptep_modify_prot_start
> >   xen:xen_mmu_ptep_modify_prot_commit
> > 
> 
> [SNIP]
> > +static const char *xen_hypercall_name(unsigned op)
> > +{
> > +	if (op < ARRAY_SIZE(xen_hypercall_names) &&
> > +	    xen_hypercall_names[op] != NULL)
> > +		return xen_hypercall_names[op];
> > +
> > +	return "";
> 
> How about defaults to "unknown" if not found?
> 

That's how the kernel 'xen_hypercall_name' handles it.

I dont mind, but I guess we want to change both sides.
I've already included Jeremy (kernel side author), so
I guess it's up to him ;-)

jirka