[solved] QEMU - Problem mit dem Durchreichen einer Soundkarte

[fireburner]

Nach dem erfolgreichen durch reichen meiner dedizierten Grafikkarte an eine Windows VM, möchte ich nun auch eine zusätzliche Soundkarte an die VM weiterreichen.
lspci -vnn zeigt folgendes zur Soundkarte:

Code: Alles auswählen

03:00.0 PCI bridge [0604]: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG PCIe to PCI Bridge [1102:7006] (prog-if 00 [Normal decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=03, secondary=04, subordinate=04, sec-latency=64
        Memory behind bridge: f7a00000-f7afffff
        Capabilities: <access denied>
        Kernel modules: shpchp

04:00.0 Audio device [0403]: Creative Labs CA0110 [Sound Blaster X-Fi Xtreme Audio] [1102:0009]
        Subsystem: Creative Labs SB1040 PCI Express [1102:0018]
        Flags: medium devsel, IRQ 19
        [virtual] Memory at f7a00000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: vfio-pci
        Kernel modules: snd_hda_intel

in meiner /etc/modprobe.d/vfio.conf habe ich sowohl mit nur dem Soundteil,

Code: Alles auswählen

options vfio-pci ids=1102:0009,1102:0018

als auch inklusive PCIe zu PCi bridge

Code: Alles auswählen

options vfio-pci ids=1102:7006,1102:0009,1102:0018

und auch mit

Code: Alles auswählen

options vfio-pci ids=1102:7006,1102:0009

versucht den vfio Treiber zuzuweisen.

Wenn ich nun in Virt-Manager die PCI Geräte 03:00.0 und 04:00.0 an die Windows VM zuweise und diese starten möchte erhalte ich folgende Fehlermeldung:

Code: Alles auswählen

Error starting domain: internal error: qemu unexpectedly closed the monitor: 2018-03-21T20:19:50.257766Z qemu-system-x86_64: -device vfio-pci,host=03:00.0,id=hostdev3,bus=pci.0,addr=0xd: vfio error: 0000:03:00.0: error getting device from group 14: No such device

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 124, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 83, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1404, in startup
    self._backend.create()
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1035, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: qemu unexpectedly closed the monitor: 2018-03-21T20:19:50.257766Z qemu-system-x86_64: -device vfio-pci,host=03:00.0,id=hostdev3,bus=pci.0,addr=0xd: vfio error: 0000:03:00.0: error getting device from group 14: No such device

Wenn ich nur 04:00.0 an die VM zuweise, wird mir in Windows zwar ein HDA controller angezeigt, der allerdings nicht funktioniert (This device cannot start. (Code10)). Daraus schließe ich das es nötig ist, die PCIe zu PCI Bridge mit an die VM zuzuweisen.

Die beiden Geräte sind die einzigen in der VFIO Gruppe 14.

Hat wer eine Idee, warum ich den Fehler bekomme?

Edit: ich nutze Debian Stretch mit dem stable kernel.

[NAB]

Uh? Ich habe noch nie eine PCIe to PCI Bridge gesehen, die ein Kernel Module benutzt. Ich kenne die nur ohne Kernel Module, und dann soll man alle daran hängenden Geräte durchreichen (also 04:00.0), nicht jedoch die Bridge selber (also 03:00.0), da vfio angeblich keine Bridges unterstützt.

Das steht auch hier so:
https://www.kernel.org/doc/Documentation/vfio.txt

This device is behind a PCIe-to-PCI bridge [4]_, therefore we also
need to add device 0000:06:0d.1 to the group following the same
procedure as above. Device 0000:00:1e.0 is a bridge that does
not currently have a host driver, therefore it's not required to
bind this device to the vfio-pci driver (vfio-pci does not currently
support PCI bridges).

Ich habe noch diese Mail von 2015 (!) ausgegraben:
https://www.redhat.com/archives/vfio-us ... 00162.html
Da versucht auch jemand, ein PCI-Gerät hinter einer PCIe to PCI Bridge mit shpchp durchzureichen. So richtig verstehe ich die Antwort von Alex Williamson nicht, aber er scheint der Meinung zu sein, dass es funktioniert und nur das Gerät selber (also 04:00.0) durchgereicht werden soll. Nur was mit dem shpchp Modul zu passieren hat, da ist er unklar ... ob das irgendwie durch vfio-pci oder pci-stub ersetzt werden muss oder ob es mit diesem Modul funktioniert.

Nebenbei ... Google meint, man kann "Code 10" auch ganz ohne Qemu/KVM/PCI-Passthrough bekommen ... geht sie denn so unter Windows?

[fireburner]

Uh? Ich habe noch nie eine PCIe to PCI Bridge gesehen, die ein Kernel Module benutzt. Ich kenne die nur ohne Kernel Module, und dann soll man alle daran hängenden Geräte durchreichen (also 04:00.0), nicht jedoch die Bridge selber (also 03:00.0), da vfio angeblich keine Bridges unterstützt.
[/quote]
Das hatte ich dann auch festgestellt. Ich habe daher vfio-pci nur dem Soundchip zugewiesen.

Nebenbei ... Google meint, man kann "Code 10" auch ganz ohne Qemu/KVM/PCI-Passthrough bekommen ... geht sie denn so unter Windows?

Da ich auf dem Rechner kein natives Windows 10 laufen habe, kann ich das leider nicht so einfach testen.
Unter Windows 7 beim Vorbesitzer lief die Karte.

Debian hatte mir vor dem Blacklisten die Karte auch in den Audioausgabe Einstellungen angezeigt.


Unter Win10 hat weder die Treiber Installation der Hersteller Treiber, noch das Deinstallieren und Neu installieren Abhilfe gebracht.

[NAB]

Du könntest in der VM mal ein Linux installieren (das Windows Image vorher sichern). Eventuell gibt Linux eine brauchbarere Fehlermeldung von sich als "Code 10". Oder die Karte geht einfach ... dann wissen wir, dass es am zickigen Windows-Treiber liegt.

Steht eigentlich irgendwas Auffälliges im "dmesg", während die Karte nicht geht? (mir ist gerade die Sache mit den MSRs wieder eingefallen, über die du bisher anscheinend nicht gestolpert bist - siehe den Wiki-Thread)

[fireburner]

Sorry für die späte Antwort.
Hier die Ausgabe von dmesg während dem Start der VM bis ins Windows: 40260

Es scheint aber nicht nur an den Treibern zu liegen.
Ich habe in der VM mal ein Debian Live System gebootet. Dort zeigt mir pavucontrol nur das Spice und die AMD Sounkarte an.
Das dmesg im LIvesystem meldet:

snd_hda_intel 0000:00:0e.0: CORB reset timeout#2, CORBRP = 65535
hdaudio hdaudioC2D0: no AFG or MFG node found
hdaudio hdaudioC2D1: no AFG or MFG node found
hdaudio hdaudioC2D2: no AFG or MFG node found
hdaudio hdaudioC2D3: no AFG or MFG node found
snd_hda_intel 0000:00:0e.0: no codecs initialized

[fireburner]

Nochmal als follow up:
Die obige Creative Soundkarte scheint defekt zu sein.

Ich hatte mir zwischenzeitlich eine gebrauchte Asus Audigy DGX geholt mit dem Ziel diese durch zu reichen.
Leider kann diese Karte nur durch gereicht werden, wenn sie eine Unique IRQ hat.
Ich habe alle PCIe Ports durchprobiert, aber immer war der Konflikt mit einem Gerät das benötigt wurde.
Allerdings konnte ich dadurch testweise die Soundkarte durch reichen, wenn ich die Grafikkarte nicht durch reichen und so feststellen, das diese (ohne durch reichen der PCI Bridge) korrekt erkannt wird vom Guest und einwandfrei funktionierte.
Vermutlich, könnte dies mit einer neueren Karte (die auch bei shared IRQs durch gereicht werden kann, wie gewünscht funktionieren.

Letztendlich habe ich das ganze Thema nun so gelöst:
Ich nutze die Asus Karte als meine Hauptausgabe am Host und reiche den auf dem Mainboard verbauten Soundchip an den Guest weiter.
Der Mainboard Chip kann dabei solange auch am Host genutzt werden bis die VM gestartet wird.