dump IPC message payload to dmesg

[xiulipan]

Dump IPC message payload to help debug and reproduce IPC message.

[wenqingfu]

Do we still need this feature? @xiulipan

[ranj063]

@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

[lyakh]

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?

[ranj063]

@lyakh I do not think they are. This is related to the issue https://github.com/thesofproject/sof/issues/766.

[xiulipan]

@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.

[lyakh]

@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.

[xiulipan]

@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?

[lyakh]

@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.

[xiulipan]

@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.

[plbossart]

@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.

[lyakh]

@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

[plbossart]

@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.

[lgirdwood]

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

[plbossart]

@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.

[tlauda]

@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.

[plbossart]

@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.