linux-kernel - Re: [PATCH] powerpc/powernv: Add kernel cmdline parameter to disable imc

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: <06fe39eb-d5fe-4472-56b4-f66390d7fad9@linux.vnet.ibm.com>
Date:   Wed, 11 Oct 2017 14:26:27 +0530
From:   Anju T Sudhakar <anju@...ux.vnet.ibm.com>
To:     Stewart Smith <stewart@...ux.vnet.ibm.com>,
        Michael Ellerman <mpe@...erman.id.au>
Cc:     linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        maddy@...ux.vnet.ibm.com, hemant@...ux.vnet.ibm.com
Subject: Re: [PATCH] powerpc/powernv: Add kernel cmdline parameter to disable
 imc

Hi mpe, stewart,


On Wednesday 11 October 2017 01:55 AM, Stewart Smith wrote:
> Michael Ellerman <mpe@...erman.id.au> writes:
>> Anju T Sudhakar <anju@...ux.vnet.ibm.com> writes:
>>
>>> Add a kernel command line parameter option to disable In-Memory Collection
>>> (IMC) counters and add documentation. This helps in debug.
>> I'd really rather we didn't. Do we *really* need this?
>>
>> We don't have command line parameters to disable any of the other ~20
>> PMUs, why is this one special?

This one is really helpful in debugging, incase if we want to proceed 
without nest counters  OR
core counters . But if we have the facility to do the same from 
petitboot, its fine.

> You could also do the same thing by editing the device tree before
> booting your kernel, we do have the facility to do that in petitboot.
>
> A recent firmware patch: https://patchwork.ozlabs.org/patch/823249/
> would fix the firmware implementation where the counters were already
> running before the INIT/START calls, which are likely the cause of the
> problems that this patch is trying to work around.
>
> I propose we have the firmware do the right thing and nothing special in
> kernel. i.e. not to merge this.
>

Agreed.



Thanks,
Anju