From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F0C32C43461 for ; Thu, 17 Sep 2020 13:01:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 870E02075B for ; Thu, 17 Sep 2020 13:01:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="ZganT4Nn" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726812AbgIQNAi (ORCPT ); Thu, 17 Sep 2020 09:00:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43790 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727109AbgIQMw7 (ORCPT ); Thu, 17 Sep 2020 08:52:59 -0400 Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22D19C061788 for ; Thu, 17 Sep 2020 05:52:56 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id bg9so1087662plb.2 for ; Thu, 17 Sep 2020 05:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8r2W5ugtK9caMpjnS4eY21V02JS4a1fk6SkCIi43SQU=; b=ZganT4NnPW+YT/mcICT/ttID3D+P4tslVZy5FHlEJa5XmVbVq7NxcMtF3KPJXHjHRi 5bvyaR1FV72putfR1BAoJ3sW9T5sX1rHs9/m2vhz2Lgzg5O6IOZz/n+cyuX5ZgM0QbjS powxnjHQEIia/bSfHG9ihbNmUIctalbqR/G7ZFoClhYDSIRjIJHEHPc+dLTRuejN3JEB B+Tdt5zCWtCu9pNf3myyAOeD7U/Lo8jdl9LA0xAcG6lrNcZNeWSplBAgHqzwEWfhVSRz /c5bdMM+PejIbELT2kx9zdsgUtMVM32LBppO/1yNMO6c5cTbZ77yYsTtwvluHoGAqCRU Xl3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8r2W5ugtK9caMpjnS4eY21V02JS4a1fk6SkCIi43SQU=; b=dAue3uvxqv+xsxME9jbnsQ+KXh7WDRSet5Ngx6ce4Cqsl8IdrpkcDN2LHL7Es/FCeD BpcjPoCAm5/k3iuGb4gIzbQBWnXnmAVj32kbnhT+VaRwXWGpkUHr/pUvdssYbsVzKabf y3F3pn3z8QbOucbOR+zQaWXlon0dLhLPvQvZ2oByrzodt71tsaLgAIzGTHuO8YuhKyVt Y4L8tg7D5TQvfCMMmssbJt+rq6PnnNXaklCdWt/OnVNEWsTsHqWZWpjSyAfCYCJKVte2 ln96nmQK/UXwDSqz02sMZSIcsbDNs1dZlC5F+nLs3UTPH0xeHXaNJeBiwEpngK6kL7ty dSDg== X-Gm-Message-State: AOAM532blIacTsyLi6aeDU7zO3h4yysbXSCigY8jykpsQuRPe1FT6Dor KRaHAzpgL1CS0EOl/mYMnA40Pg== X-Google-Smtp-Source: ABdhPJy3oI3H4XEMYD6/9IZe1EzBQKyrfIum9IoJh0QneN+UTJHIhS1pkrhM0Nm+ERmAhGon9KAXvQ== X-Received: by 2002:a17:902:7c83:b029:d1:e603:af74 with SMTP id y3-20020a1709027c83b02900d1e603af74mr10646316pll.82.1600347175474; Thu, 17 Sep 2020 05:52:55 -0700 (PDT) Received: from leoy-ThinkPad-X240s ([2600:3c01::f03c:91ff:fe8a:bb03]) by smtp.gmail.com with ESMTPSA id 126sm7044154pfg.192.2020.09.17.05.52.50 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 Sep 2020 05:52:54 -0700 (PDT) Date: Thu, 17 Sep 2020 20:52:46 +0800 From: Leo Yan To: Marc Zyngier Cc: Sergey Senozhatsky , Arnaldo Carvalho de Melo , Mark Rutland , Peter Zijlstra , Will Deacon , John Garry , Mathieu Poirier , Namhyung Kim , Suleiman Souhlal , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCHv3] perf kvm: add kvm-stat for arm64 Message-ID: <20200917125246.GF12548@leoy-ThinkPad-X240s> References: <20200917003645.689665-1-sergey.senozhatsky@gmail.com> <20200917100950.GC12548@leoy-ThinkPad-X240s> <20200917101219.GD12548@leoy-ThinkPad-X240s> <652f10660f09bd608b825233713f775a@kernel.org> <20200917114231.GE12548@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 17, 2020 at 12:53:02PM +0100, Marc Zyngier wrote: > On 2020-09-17 12:42, Leo Yan wrote: > > On Thu, Sep 17, 2020 at 11:21:15AM +0100, Marc Zyngier wrote: > > > > [...] > > > > > > > > +const char *vcpu_id_str = "id"; > > > > > > > > > > On Arm64, ftrace tracepoint "kvm_entry" doesn't contain the field "id" > > > > > or field "vcpu_id", thus it always reads out the "id" is 0 and it is > > > > > recorded into Perf's structure vcpu_event_record::vcpu_id and assigned > > > > > to perf thread's private data "thread::private". > > > > > > > > > > With current code, it will not mess up different vcpus' samples > > > > > because > > > > > now the samples are analyzed based on thread context, but since all > > > > > threads' "vcpu_id" is zero, thus all samples are accounted for > > > > > "vcpu_id=0" and cannot print out correct result with option "--vcpu": > > > > > > > > > > > > > > > $ perf kvm stat report --vcpu 4 > > > > > > > > > > Analyze events for all VMs, VCPU 4: > > > > > > > > > > VM-EXIT Samples Samples% Time% Min Time > > > > > Max Time Avg time > > > > > > > > > > Total Samples:0, Total events handled time:0.00us. > > > > > > > > > > > > > > > This is an issue I observed, if we want to support option "--vcpu", > > > > > seems we need to change ftrace event for "kvm_entry", but this will > > > > > break ABI. > > > > > > > > > > Essentially, this issue is caused by different archs using different > > > > > format for ftrace event "kvm_entry", on x86 it contains feild > > > > > "vcpu_id" but arm64 only just records "vcpu_pc". > > > > > > > > > > @Marc, @Will, do you have any suggestion for this? Do you think it's > > > > > feasible to add a new field "vcpu_id" into the tracepoint "kvm_entry" > > > > > for Arm64's version? > > > > > > The question really is: how will you handle the ABI breackage? > > > I don't see a good solution for it, apart from having a *separate* > > > tracepoint that collects all the information you need. And even that > > > is > > > really ugly. > > > > I searched a bit and found in practice it's not impossible to add new > > parameters for existed tracepoint, e.g. [1][2] are two examples to add > > new parameters for existed tracepoints and have been merged into > > mainline kernel. IIUC, we keep the old parameters for a tracepoint > > so this can avoid to break ABI if any apps have used this tracepoint, > > and adding a new parameter for the tracepoint should be safe. > > > > If you agree with this, I'd like to suggest to apply below change. > > How about you think for this? > > > > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > > index 46dc3d75cf13..d9f9b8e1df77 100644 > > --- a/arch/arm64/kvm/arm.c > > +++ b/arch/arm64/kvm/arm.c > > @@ -736,7 +736,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) > > /************************************************************** > > * Enter the guest > > */ > > - trace_kvm_entry(*vcpu_pc(vcpu)); > > + trace_kvm_entry(vcpu->vcpu_id, *vcpu_pc(vcpu)); > > guest_enter_irqoff(); > > > > ret = kvm_call_hyp_ret(__kvm_vcpu_run, vcpu); > > diff --git a/arch/arm64/kvm/trace_arm.h b/arch/arm64/kvm/trace_arm.h > > index 4691053c5ee4..e1d3e7a67e8b 100644 > > --- a/arch/arm64/kvm/trace_arm.h > > +++ b/arch/arm64/kvm/trace_arm.h > > @@ -12,18 +12,20 @@ > > * Tracepoints for entry/exit to guest > > */ > > TRACE_EVENT(kvm_entry, > > - TP_PROTO(unsigned long vcpu_pc), > > - TP_ARGS(vcpu_pc), > > + TP_PROTO(unsigned int vcpu_id, unsigned long vcpu_pc), > > + TP_ARGS(vcpu_id, vcpu_pc), > > > > TP_STRUCT__entry( > > + __field( unsigned int, vcpu_id ) > > __field( unsigned long, vcpu_pc ) > > ), > > > > TP_fast_assign( > > + __entry->vcpu_id = vcpu_id; > > __entry->vcpu_pc = vcpu_pc; > > ), > > > > - TP_printk("PC: 0x%08lx", __entry->vcpu_pc) > > + TP_printk("vcpu: %u, PC: 0x%08lx", __entry->vcpu_id, __entry->vcpu_pc) > > ); > > > > TRACE_EVENT(kvm_exit, > > > > How is that not breaking the ABI? You are adding a new field, and anything > that expect to read 'PC: 0x.....' at the beginning of the line now fails. > The examples you give are also blatant ABI breakages. because it is done > somewhere else doesn't make it valid. > > Anything that can be parsed by userspace is ABI. If you don't believe me, > please read the entertaining discussion we had when we tried to drop > Bogomips from /proc/cpuinfo. The discussion thread was too long [1] to read all replies :) ... but I understand we should be very careful for ABI breakage. > So unless you get me Linus' stamp of approval for this, it's not happening. > Feel free to add a *new* tracepoint instead. Okay, thanks for the info and suggestions. Thanks, Leo [1] https://lkml.org/lkml/2015/1/4/132 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 69DD2C2BBD1 for ; Thu, 17 Sep 2020 12:54:44 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E9C2421974 for ; Thu, 17 Sep 2020 12:54:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="2dZhptUR"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="ZganT4Nn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E9C2421974 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=K//Lxm+NYib00sV97U2MNb0MZvqEC8jAEOcq0/9ORhg=; b=2dZhptUROoZ1hQbxL6dXiOK9P iiwbUyJ/IQHfIumf9Xt+26YgldncJViRlxI5LKdQXGnGW20j2VyYrkEAblTE3pXxliPzN3xQZAvsn ZZxEfxP1tF/vjKUDNKlKjbt2M5dtJzgOkx0+QW18HPxYav6HVpnQm0J7h7QevO53u0BkGFWApRf1l zVpJmqIh5o1R+NiIEwY3DgZ1qz4iG9aK4VXbIvyfacTjjOzErFWbKVSSAAJc34ewcvk1iVSeah5zW MHtpDOW8rYNPRADwSdQeiuKx0Qp3rmBZyB/UnEFJpQBGkgKBrJc5+HWwnVi3iFAqmcFGo9BClxsP0 B5LmFSOlA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kItPM-0006mj-Tv; Thu, 17 Sep 2020 12:53:04 +0000 Received: from mail-pl1-x643.google.com ([2607:f8b0:4864:20::643]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kItPF-0006kS-VF for linux-arm-kernel@lists.infradead.org; Thu, 17 Sep 2020 12:52:59 +0000 Received: by mail-pl1-x643.google.com with SMTP id x18so1075865pll.6 for ; Thu, 17 Sep 2020 05:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=8r2W5ugtK9caMpjnS4eY21V02JS4a1fk6SkCIi43SQU=; b=ZganT4NnPW+YT/mcICT/ttID3D+P4tslVZy5FHlEJa5XmVbVq7NxcMtF3KPJXHjHRi 5bvyaR1FV72putfR1BAoJ3sW9T5sX1rHs9/m2vhz2Lgzg5O6IOZz/n+cyuX5ZgM0QbjS powxnjHQEIia/bSfHG9ihbNmUIctalbqR/G7ZFoClhYDSIRjIJHEHPc+dLTRuejN3JEB B+Tdt5zCWtCu9pNf3myyAOeD7U/Lo8jdl9LA0xAcG6lrNcZNeWSplBAgHqzwEWfhVSRz /c5bdMM+PejIbELT2kx9zdsgUtMVM32LBppO/1yNMO6c5cTbZ77yYsTtwvluHoGAqCRU Xl3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=8r2W5ugtK9caMpjnS4eY21V02JS4a1fk6SkCIi43SQU=; b=rP1W83Z+ZHwaUJt/6hhWraGZkCBc47YRjHmgD4nDl/xweIdmehyjOHXu08DoS0or83 krWM3hJxqW6txfEFTABJbOYDpKRPZBd33WUE4/MoRznLNMULyjMjsyKMAqlBTziRNzF+ XAxPFqAJx0V42fKsEhAlzSuGicYGT3sp8aXIhD9vcZpwoGmO0upQegQkfj5jvwHClILp CvSYSOIPuKWPKA4E9czIn/MNDRFWp6cnGzoKWwD2C5WC+sNaloWbR7GeJDkzMTx2lCWN Q7tMIEXPr3I67VTveYa6rXXmGAjEIhxbJzZkb2r71DHae/6PNvlCDL6mLXXPfDdSGgZJ Il1Q== X-Gm-Message-State: AOAM530YfTWsDzL2QOQOJ2+f32ci0ytquCSPB7h0HJM6Jd+qU9Onshuj PfZv5avpaphKdpQLQnpXlLaxog== X-Google-Smtp-Source: ABdhPJy3oI3H4XEMYD6/9IZe1EzBQKyrfIum9IoJh0QneN+UTJHIhS1pkrhM0Nm+ERmAhGon9KAXvQ== X-Received: by 2002:a17:902:7c83:b029:d1:e603:af74 with SMTP id y3-20020a1709027c83b02900d1e603af74mr10646316pll.82.1600347175474; Thu, 17 Sep 2020 05:52:55 -0700 (PDT) Received: from leoy-ThinkPad-X240s ([2600:3c01::f03c:91ff:fe8a:bb03]) by smtp.gmail.com with ESMTPSA id 126sm7044154pfg.192.2020.09.17.05.52.50 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 Sep 2020 05:52:54 -0700 (PDT) Date: Thu, 17 Sep 2020 20:52:46 +0800 From: Leo Yan To: Marc Zyngier Subject: Re: [PATCHv3] perf kvm: add kvm-stat for arm64 Message-ID: <20200917125246.GF12548@leoy-ThinkPad-X240s> References: <20200917003645.689665-1-sergey.senozhatsky@gmail.com> <20200917100950.GC12548@leoy-ThinkPad-X240s> <20200917101219.GD12548@leoy-ThinkPad-X240s> <652f10660f09bd608b825233713f775a@kernel.org> <20200917114231.GE12548@leoy-ThinkPad-X240s> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200917_085258_058974_DFE5B68F X-CRM114-Status: GOOD ( 38.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Mathieu Poirier , Peter Zijlstra , John Garry , linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo , Sergey Senozhatsky , Suleiman Souhlal , Namhyung Kim , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Sep 17, 2020 at 12:53:02PM +0100, Marc Zyngier wrote: > On 2020-09-17 12:42, Leo Yan wrote: > > On Thu, Sep 17, 2020 at 11:21:15AM +0100, Marc Zyngier wrote: > > > > [...] > > > > > > > > +const char *vcpu_id_str = "id"; > > > > > > > > > > On Arm64, ftrace tracepoint "kvm_entry" doesn't contain the field "id" > > > > > or field "vcpu_id", thus it always reads out the "id" is 0 and it is > > > > > recorded into Perf's structure vcpu_event_record::vcpu_id and assigned > > > > > to perf thread's private data "thread::private". > > > > > > > > > > With current code, it will not mess up different vcpus' samples > > > > > because > > > > > now the samples are analyzed based on thread context, but since all > > > > > threads' "vcpu_id" is zero, thus all samples are accounted for > > > > > "vcpu_id=0" and cannot print out correct result with option "--vcpu": > > > > > > > > > > > > > > > $ perf kvm stat report --vcpu 4 > > > > > > > > > > Analyze events for all VMs, VCPU 4: > > > > > > > > > > VM-EXIT Samples Samples% Time% Min Time > > > > > Max Time Avg time > > > > > > > > > > Total Samples:0, Total events handled time:0.00us. > > > > > > > > > > > > > > > This is an issue I observed, if we want to support option "--vcpu", > > > > > seems we need to change ftrace event for "kvm_entry", but this will > > > > > break ABI. > > > > > > > > > > Essentially, this issue is caused by different archs using different > > > > > format for ftrace event "kvm_entry", on x86 it contains feild > > > > > "vcpu_id" but arm64 only just records "vcpu_pc". > > > > > > > > > > @Marc, @Will, do you have any suggestion for this? Do you think it's > > > > > feasible to add a new field "vcpu_id" into the tracepoint "kvm_entry" > > > > > for Arm64's version? > > > > > > The question really is: how will you handle the ABI breackage? > > > I don't see a good solution for it, apart from having a *separate* > > > tracepoint that collects all the information you need. And even that > > > is > > > really ugly. > > > > I searched a bit and found in practice it's not impossible to add new > > parameters for existed tracepoint, e.g. [1][2] are two examples to add > > new parameters for existed tracepoints and have been merged into > > mainline kernel. IIUC, we keep the old parameters for a tracepoint > > so this can avoid to break ABI if any apps have used this tracepoint, > > and adding a new parameter for the tracepoint should be safe. > > > > If you agree with this, I'd like to suggest to apply below change. > > How about you think for this? > > > > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > > index 46dc3d75cf13..d9f9b8e1df77 100644 > > --- a/arch/arm64/kvm/arm.c > > +++ b/arch/arm64/kvm/arm.c > > @@ -736,7 +736,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu) > > /************************************************************** > > * Enter the guest > > */ > > - trace_kvm_entry(*vcpu_pc(vcpu)); > > + trace_kvm_entry(vcpu->vcpu_id, *vcpu_pc(vcpu)); > > guest_enter_irqoff(); > > > > ret = kvm_call_hyp_ret(__kvm_vcpu_run, vcpu); > > diff --git a/arch/arm64/kvm/trace_arm.h b/arch/arm64/kvm/trace_arm.h > > index 4691053c5ee4..e1d3e7a67e8b 100644 > > --- a/arch/arm64/kvm/trace_arm.h > > +++ b/arch/arm64/kvm/trace_arm.h > > @@ -12,18 +12,20 @@ > > * Tracepoints for entry/exit to guest > > */ > > TRACE_EVENT(kvm_entry, > > - TP_PROTO(unsigned long vcpu_pc), > > - TP_ARGS(vcpu_pc), > > + TP_PROTO(unsigned int vcpu_id, unsigned long vcpu_pc), > > + TP_ARGS(vcpu_id, vcpu_pc), > > > > TP_STRUCT__entry( > > + __field( unsigned int, vcpu_id ) > > __field( unsigned long, vcpu_pc ) > > ), > > > > TP_fast_assign( > > + __entry->vcpu_id = vcpu_id; > > __entry->vcpu_pc = vcpu_pc; > > ), > > > > - TP_printk("PC: 0x%08lx", __entry->vcpu_pc) > > + TP_printk("vcpu: %u, PC: 0x%08lx", __entry->vcpu_id, __entry->vcpu_pc) > > ); > > > > TRACE_EVENT(kvm_exit, > > > > How is that not breaking the ABI? You are adding a new field, and anything > that expect to read 'PC: 0x.....' at the beginning of the line now fails. > The examples you give are also blatant ABI breakages. because it is done > somewhere else doesn't make it valid. > > Anything that can be parsed by userspace is ABI. If you don't believe me, > please read the entertaining discussion we had when we tried to drop > Bogomips from /proc/cpuinfo. The discussion thread was too long [1] to read all replies :) ... but I understand we should be very careful for ABI breakage. > So unless you get me Linus' stamp of approval for this, it's not happening. > Feel free to add a *new* tracepoint instead. Okay, thanks for the info and suggestions. Thanks, Leo [1] https://lkml.org/lkml/2015/1/4/132 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel