KVM PCI-passthrough in Lenny

[heinzi]

Hallo,

Mein PC hat eine CPU mit Vt (Intel Pentium Dual Core) und ein Mainboard mit Vt-d.
ich habe ein Lenny-System aufgesetzt und über lenny-backports folgendes installiert:
- Kernel 2.6.30-bpo.1-amd64
- kvm 85
- libvirt 0.6.5-3
Nun habe ich mit libvirt eine virtuelle Maschine mit Ubuntu 9.10 erstellt und gestartet - läuft fehlerfrei mit kvm.
Allerdings möchte ich dieser VM nun eine PCI-Karte (WLAN) durchreichen.
Ich habe die entsprechenden Zeilen in die xml-Datei eingetragen und virsh define ausgeführt. Anschließend kann ich die Domain auch wie bisher mit virsh start starten, allerdings ist die PCI-Karte im Gast nicht vorhanden und in /var/log/libvirt/qemu/pcitest.log steht:

Code: Alles auswählen

asign_irq: deassign: Invalid argument
Failed to assign irq for "03:00.0": Input/output error
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to deassign device "03:00.0": Invalid argument

dmesg gibt folgendes aus:

Code: Alles auswählen

[1635.381785] pci-stub 0000:03:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
[1635.479408] kvm: failed to enable INTx device!
[1635.479430] pci-stub 0000:03:00.0: PCI INT A disabled
[1635.479566] kvm_vm_ioctl_deassign_device: device hasn't been assigned bevore, so cannot be deassigned

Ich weiß aber, dass der IRQ der Karte nicht geshared ist, da laut lspci -v meine Karte den IRQ 20 hat:

Code: Alles auswählen

03:00.0 Network controller: Atheros Communications Inc. AR5416 802.11abgn Wireless PCI Adapter (rev 01)
   Subsystem: Atheros Communications Inc. Device 3079
   Flags: 66MHz, medium devsel, IRQ 20
   Memory at f3500000 (32-bit, non-prefetchable) [size=64K]
   Capabilities: [40] #80 [0000]
   Kernel driver in use: pci-stub
   Kernel modules: ath9k

und es sonst keine Karte mit IRQ 20 gibt:

Code: Alles auswählen

#lspci -vgrep "IRQ 20"
Flags: 66MHz, medium devsel, IRQ 20
#

Hier noch die XML-Datei der virtuellen Maschine (pcitest.xml):

Code: Alles auswählen

<domain type='kvm'>
  <name>ownpcitest</name>
  <uuid>aa84ffa5-f017-eb30-91eb-823692ffb595</uuid>
  <memory>524288</memory>
  <currentMemory>524288</currentMemory>
  <vcpu>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
  </features>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='block' device='disk'>
      <source dev='/dev/system/ownpcitest'/>
      <target dev='hda' bus='ide'/>
    </disk>
    <disk type='block' device='cdrom'>
      <target dev='hdc' bus='ide'/>
      <readonly/>
    </disk>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target port='0'/>
    </console>
    <input type='mouse' bus='ps2'/>
    <graphics type='vnc' port='5901' autoport='no' keymap='de'/>
    <hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
      </source>
    </hostdev>
  </devices>
</domain>

Aber eigentlich kann es nicht an libvirt liegen, denn wenn ich den Aufruf von libvirt an kvm aus der Logdatei kopiere und direkt ausführe

Code: Alles auswählen

LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/ /usr/bin/kvm -M pc -m 512 -smp 1 -name pcitest -uuid aa84ffa5-f017-eb30-91eb-823692ffb595 -monitor pty -boot c -drive file=/dev/system/pcitest,if=ide,index=0,boot=on -drive file=,if=ide,media=cdrom.index=2 -net none -serial pty -parallel none -usb -vnc 0.0.0.0:1 -k de -pcidevice host=03:00.0

bekomme ich exakt die selbe Fehlermeldung. Wenn ich das -pcidevide am Ende weglasse, funktioniert es wieder. Also liegt es entweder an diesem KVM-Aufruf den libvirt irgendwie falsch zusammenstellt, oder es liegt an kvm.
Es kann auch kein Hardwarefehler sein, da der PCI-Passthrough genau dieser Karte in genau diesem PCI-Slot mit Fedora 11 out of the box funktioniert (allerdings habe ich dort die VM nicht durch virtinst und Manipulation der XML-Datei, sondern mit dem virt-manager von fedora erstellt und ich habe auch im virt-manager von fedora das PCI-Passthrough eingesetellt).
Woran könnte das liegen?

Grüße,
Heinzi

[falstaff]

Hi Heinzi,

bekomme ich exakt die selbe Fehlermeldung. Wenn ich das -pcidevide am Ende weglasse, funktioniert es wieder. Also liegt es entweder an diesem KVM-Aufruf den libvirt irgendwie falsch zusammenstellt, oder es liegt an kvm.

Ich verstehe nicht genau was du damit sagen willst. Wenn du das pcidevice weglässt, funktioniert die PCI-Karte im Gast? Oder der Gast bootet einfach, jedoch ohne Karte? Das zweite ist ja zu erwarten...

Poste doch den Output von:

Code: Alles auswählen

cat /proc/interrupts

Ich denke es liegt am Kernel. Welche Version hast du unter Fedora verwendet?

Gruss
falstaff

[heinzi]

Hallo,

danke für deine Antwort

Bei Fedora 11 lief das ganze unter der Standardinstallation direkt ohne irgendwelche Modifikationen.
Wenn ich unter Debian das -pcidevice im KVM-Aufruf weglasse bootet die VM wie du angemerkt hast natürlich ohne das PCI-Gerät, aber sie bootet immerhin.

Das oben beschriebene Problem hat sich übrigens inzwischen folgendermaßen verschoben:
Ich habe den Debiankernel selbst kompilert und dabei die unter http://www.linux-kvm.org/page/How_to_as ... T-d_in_KVM beschriebenen Kernelmodule einkompiliert (die haben in der Standardinstallation scheinbar gefehlt).
Seither funktioniert der Aufruf (auch mit libvirt) und lspci im Gast zeigt mir die Karte an.
Allerdings funktioniert die Karte nicht. Wenn ich direkt auf dem Host-PC eine Ubuntu 9.10 - LiveCD laufen lasse, kann ich damit die WLan-Karte nutzen und mich in die WLan-Netze hier verbinden. Wenn ich allerdings die selbe LiveCD als KVM-Gast laufen lasse, findet er keine Netzwerke, lspci zeigt die Karte aber an.

Da das ursprüngliche Problem gelöst ist (und dadurch ein neues entstanden ist ) denke ich, dass dir die Ausgabe von /proc/interrupts nichts mehr bringen würde, oder? Was für Configdateien oder Logdateien würden bei der Lösung weiterhelfen?

Grüße,
Heinzi