QemuHDADump
QemuHDADump copied to clipboard
Conmanx360
Some changes for consideration
tl;dr: Realtime output of CORB verbs as they are issued by the device driver, instead of having to post-process memory dumps of the CORB buffer space after the fact. Plus a pile of less-visible work.
This is the result of about three days of filing off rough edges, reworking basic concepts, and trying to figure out how to interpret the output from QemuHDADump. The basic idea was good, but the implementation needed a bit of work.
The basic changes start with the addition of a Makefile, and the use of /dev/tty instead of having to have the current tty device on the command line.
Switching from dead-reckoning within the text representation of an event to working with a parsed event structure somewhat simplified the core logic, except for where the original semantics were incomprehensible to me.
The real trick was finding a way to transfer "physical" memory contents from the VM directly to QemuHDADump instead of having to leave them in files. That, plus a model of the DMA engine meant being able to print the verbs directly as they come through (and not missing any due to the driver issuing more than one at once, especially if it does so around the end of the ring buffer), splitting out the codec and node ids at the same time.
I left the original CORB memory dumping logic in place as best I could, in case it provided some benefit that wasn't immediately apparent (it's dumping about four times as much data as necessary for even the largest CORB, and I see something about the RIRB in one of the auxiliary programs, so there may be something accidentally-useful going on with a windows driver or something).
Hi! Sorry, I haven't checked github in awhile and must have missed the email they sent... Give me a little bit to review through all of this and check it out. I agree, the original implementation was not very good, it was written back when I had only a few months of programming experience, so it's to be expected. If you have any questions, feel free to shoot me an e-mail or use IRC, I'm always on freenode channel #ca0132.
Being new to this, it's neat to see someone else take an idea and fix it up. Okay. Now time to look through it. :)
Most of it looks good, before I merge, have you tested to make sure it works? I will do that tomorrow or so, I'm kind of busy at the moment. Just want to make sure I don't break any functionality.
Also, you mentioned it, but I like to maintain the frame file dumps because it's easier for me to read them using the program to merge them all together, and then outputting them as hexadecimal unsigned ints. Easier to split it up that way. Also, the RIRB can be extracted, which gives me access to what the responses are. I haven't used it too much, but it has come in handy a few times.
Before you merge, I would recommend testing to make sure that I haven't broken anything. Appearances could be deceiving, after all! I hope that I haven't broken anything that you've been relying on, but at the same time I haven't been able to do anything useful with that workflow, so there are limits to what I can test in that direction.