linux-kernel - Re: [PATCH v2 2/3] perf kvm: enable record|report feature on powerpc

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 for Android: free password hash cracker in your pocket

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

Message-ID: <56B9C3C8.2010707@linux.vnet.ibm.com>
Date:	Tue, 9 Feb 2016 16:17:36 +0530
From:	Ravi Bangoria <ravi.bangoria@...ux.vnet.ibm.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:	mingo@...nel.org, peterz@...radead.org,
	linux-kernel@...r.kernel.org, hemant@...ux.vnet.ibm.com,
	"Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
	mpe@...erman.id.au, paulus@...abs.org
Subject: Re: [PATCH v2 2/3] perf kvm: enable record|report feature on powerpc

Hi acme,

On Tuesday 02 February 2016 02:36 PM, Ravi Bangoria wrote:
> HI acme,
>
> On Tuesday 02 February 2016 02:36 AM, Arnaldo Carvalho de Melo wrote:
>> Em Fri, Jan 22, 2016 at 11:28:11AM +0530, Ravi Bangoria escreveu:
>>> +    return event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK;
>>> +}
>> This hunk and the next should be on the previous patch, that is not even
>> compiling...
>>
>> You have to compile patch by patch, we can't just test at the end of a
>> patchkit like this, this destroys bisection ;-\
>
> Didn't aware about that. Will take care of compiling each patch
> separately next time onwards.
>
>> Also you first need to put in place a way to override how to obtain the
>> cpumode, then you should use it.
>>
>> Also this mode doesn't look feasible at all, think about processing
>> perf.data files generated in !powerpc systems being analysed in a
>> powerpc system. This has to be dependend on the architecture of the
>> machine where the perf.data file was recorded, not on the archictecture
>> of the machine the binary was built for.
>
> Valid point.
>
> I'll re-think about approach in this case.
>

I've analyzed the approach. Here is my observations:

1. With the current approach, record on !powerpc and report on powerpc
will work as we are solely dependent on tracepoint; so we don't change ip
and cpumode of sample if it's not of kvm_hv:kvm_guest_exit.

2. However, record on powerpc and report on !powerpc won't work with the
current approach. To enable that, we have two options:

Option A. Change ip and cpumode of sample at a time of record.
This will add overhead at a time of recording data and it may have
bad effect like data lost.

Option B. Extension to current approach (change ip and cpumode at
report time only).
I'll need to move 'most of' the code from arch/powerpc/util/kvm.c into
some common code which is included on all architectures. And use
this code to make decision about changing ip and cpumode of sample
at run time. So these functions needs to be present in a binary,
no matter which platform it's compiled on.

I want your suggestions here, how best we can achieve that?

Regards,
Ravi