dump IPC message payload to dmesg about linux HOT 16 OPEN

Do we still need this feature? @xiulipan

from linux.

@wenqingfu yes we do need this feature. This will be very helpful in making sure the IPC payload isnt tainted before it is sent to the DSP

from linux.

I actually wanted to have a "dump IPC" feature but for a completely different reason - to use a live system to record topology IPC messages to then create an object from those messages to be integrated with the DSP firmware image for the host-less mode. But I would actually use something different than the kernel logging for that. Something like debugfs / /proc / netlink or even a new ioctl to an existing device node... But I'm not sure how IPCs can be tainted - don't we have a much larger problem if IPC messages can be tainted on a system? @ranj063 could you clarify?

from linux.

@lyakh I do not think they are. This is related to the issue thesofproject/sof#766.

from linux.

@lyakh
Actually this feature originally is about reproduce some bug on host-less DSP on QEMU or some other simulator. And I think that is just what you think?
@ranj063
Good point! I think this will also have benefit about this kind of bugs. To help us make sure the payload is what we expect.

from linux.

@ranj063 @xiulipan @wenqingfu what if we do this as a debugfs file with a blocking read? I'm not a huge fan of polluting the kernel log with potentially many (dozens? hundreds?) messages per second.

from linux.

@lyakh
The point is that, we could not know when to read the payload from debugfs. The IPC is pretty quick to send.
Or you suggest we have another debugfs to store all IPC message in history order?

from linux.

@xiulipan it would be a different debugfs file, sure, similar to the logger. Yes, you would have to capture it explicitly, it wouldn't be saved automatically, and it would be more difficult to synchronise IPC messages with the rest of debugging output. So, we have to weigh the pros and the cons.

from linux.

@lyakh
That sound reasonable.
And if we could know what is the input date format for the host-less DSP system, then we can directly output in that format.

from linux.

@lyakh can you confirm you are working on this? there's been no update since Feb 14. I believe this is needed to help our firmware colleagues reproduce issues with the scripts.

from linux.

@plbossart @lgirdwood I'd like to have some more opinions on my proposal to implement this as a debugfs file in addition to @xiulipan's comment

from linux.

@lyakh I don't see any problems with saving the IPC payload with an appropriate format and time stamping in a debugfs file. We already have too many logs in dmesg, and adding all the content in dmesg isn't scalable/usable.

from linux.

@plbossart Mark had preference for this going via trace as ASCII hex data.

from linux.

@lgirdwood i was indicating my preference for a solution that doesn't rely on dmesg - as described in the title. we could do the debugfs first and then add the integration in the Linux trace. The latter would also need to be done for the sof-logger DSP trace btw if we want to be consistent.

from linux.

@plbossart @lgirdwood @wenqingfu @lbetlej Could we prioritize this feature? By parsing dumped payload we could recreate many sequences using our slim driver, which would speed up the process of debugging issues. The similar mechanism worked great for Windows. Of course to recreate the correct sequence the log would need to also have some additional information, like host stream buffer info, stream trigger etc.

from linux.

@tlauda what do you mean with additional information? If we dump the IPC payload in debugfs you'll get the IPC payload. If you want more context for this to be useful, then we'd have to instrument all IPC usages and define a syntax for what you want.

from linux.