netdev - Re: [PATCH net-next 0/5][pull request] add v2 FW logging for ice driver

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: <319b4a93-bdaf-e619-b7ae-2293b2df0cca@intel.com>
Date:   Mon, 13 Feb 2023 15:46:53 -0800
From:   Paul M Stillwell Jr <paul.m.stillwell.jr@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>,
        Tony Nguyen <anthony.l.nguyen@...el.com>
CC:     <davem@...emloft.net>, <pabeni@...hat.com>, <edumazet@...gle.com>,
        <netdev@...r.kernel.org>, <jacob.e.keller@...el.com>,
        <jiri@...dia.com>, <idosch@...sch.org>
Subject: Re: [PATCH net-next 0/5][pull request] add v2 FW logging for ice
 driver

On 2/10/2023 8:23 PM, Jakub Kicinski wrote:
> Can you describe how this is used a little bit?
> The FW log is captured at some level always (e.g. warns)
> or unless user enables _nothing_ will come out?
> 

My understanding is that the FW is constantly logging data into internal 
buffers. When the user indicates what data they want and what level they 
want then the data is filtered and output via either the UART or the 
Admin queues. These patches retrieve the FW logs via the admin queue 
commands.

The output from the FW is a binary blob that a user would send back to 
Intel to be decoded. This is only used for troubleshooting issues where 
a user is working with someone from Intel on a specific problem.

Does that help?

> On Thu,  9 Feb 2023 11:06:57 -0800 Tony Nguyen wrote:
>> devlink dev param set <pci dev> name fwlog_enabled value <true/false> cmode runtime
>> devlink dev param set <pci dev> name fwlog_level value <0-4> cmode runtime
>> devlink dev param set <pci dev> name fwlog_resolution value <1-128> cmode runtime
> 
> If you're using debugfs as a pipe you should put these enable knobs
> in there as well.

My understanding is that debugfs use as a write mechanism is frowned on. 
If that's not true and if we were to submit patches that used debugfs 
instead of devlink and they would be accepted then I'll happily do that. :)

Or add a proper devlink command to carry all this
> information via structured netlink (fw log + level + enable are hardly
> Intel specific).

I don't know how other companies FW interface works so wouldn't assume 
that I could come up with an interface that would work across all devices.

Paul