Glad to see this bug report isn't completely dead.
Can confirm too that the problem still exists with kernel 4.2.0-27-generic with the same motherboard as per the original bug report.
The attached is a recent extract from dmesg outputs...I use vfio passthrough for GFX on a Windows guest. You can see from the timestamps that I start the guest at 21:02:44 and at around 21:26:07 I get some DMAR faults pertain to device at 00:02.0. This device is the Intel IGD...
...not sure if this is related to the HDMI audio or not.
What I can say is that I have to boot the host with "intel_iommu=on". If I change this to =on,igfx_off then my syslog fills with constant complaints about DMAR for another device I use in passthrough which works perfectly with =on, this device is a DVB-S2 device. If I use =igfx_off this stops IOMMU so I can not longer passthrough PCI devices but presto the HDMI audio now works?!
Glad to see this bug report isn't completely dead.
Can confirm too that the problem still exists with kernel 4.2.0-27-generic with the same motherboard as per the original bug report.
The attached is a recent extract from dmesg outputs...I use vfio passthrough for GFX on a Windows guest. You can see from the timestamps that I start the guest at 21:02:44 and at around 21:26:07 I get some DMAR faults pertain to device at 00:02.0. This device is the Intel IGD...
lspci -s 00:02.0
00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06)
...not sure if this is related to the HDMI audio or not.
What I can say is that I have to boot the host with "intel_iommu=on". If I change this to =on,igfx_off then my syslog fills with constant complaints about DMAR for another device I use in passthrough which works perfectly with =on, this device is a DVB-S2 device. If I use =igfx_off this stops IOMMU so I can not longer passthrough PCI devices but presto the HDMI audio now works?!