Comment 17 for bug 1721987

Obviously contacting my vendor went nowhere.

While doing more testing, I get the same result of audio only through one speaker in Windows 10 with the default audio drivers that Windows ships with. The Realtek/Dolby audio drivers from the vendor (Huawei) need to be installed in order to get sound out of both speakers in Windows, too.

I've been playing with VFIO to be able to boot Linux and hand off the PCI audio device to Windows 10 inside of qemu with the proper Realtek Windows drivers installed. This allows me to log all of the PCI IO activity from qemu.

While doing this, I noticed that if I boot Windows 10 in qemu, then boot Linux in qemu, audio works in Linux through both speakers with no other changes. This only works through qemu/VFIO, as rebooting the full system resets the PCI device.

So something must be getting initialized or toggled on the device in Windows that affects the device through to initialization in Linux. One of the pins that the device presents is configured slightly different in Linux after booting Windows first (nid 0x19 0x411111f0 -> 0x811111f0), and I've tried explicitly setting that pin configuration in Linux without booting Windows first but it has no effect.

I have qemu logging all of the VFIO PCI reads and writes under Windows, and I instrumented some custom code to store the RIRBLBASE and CORBLBASE values and then print out the contents of those DMA addresses (+ current queue offset) whenever CORBWP/RIRBWP are written to, in order to be able to see the commands submitted to the CORB and the response from the RIRB when running Windows.

Is there anything else similar to the CORB/RIRB that I should be logging to try to see what else the Windows driver could be doing?

VFIO limits the emulated Windows instance to see only the PCI audio device, so there is no ACPI configuration or other IO that it could be doing other than PCI config read/write, PCI region read/write, and DMA with the audio device. But still, there must be something the