Libvirt+KVM, PCI-Passthrough bereitet Schwierigkeiten

[vitaminb]

Hallo,

ich bin hier dabei eine virtuelle Maschine einzurichten die den direkten Zugriff auf eine PCI-Netzwerkkarte haben soll. Mein Host-System ist ein Supermicro X8SIL-F mit einer Xeon L3406 CPU und 8 GB ECC RAM. Installiert ist ein aktuelles Debian Squeeze mit Kernel 2.6.32-5-amd64 und libvirt-bin 0.9.8 aus den Backports.

Die Netzwerkkarte ist von D-Link und hat einen RTL8139 Chip, Kernelmodul 8139too.

Informationen zur Hardware:

Code: Alles auswählen

dmesg | grep -e DMAR -e IOMMU
[    0.000000] ACPI: DMAR 00000000bf7b00f0 00090 (v01    AMI  OEMDMAR 00000001 MSFT 00000097)
[    0.000000] Intel-IOMMU: enabled
[    0.037674] DMAR: Host address width 36
[    0.037677] DMAR: DRHD base: 0x000000fed93000 flags: 0x1
[    0.037684] IOMMU fed93000: ver 1:0 cap c9008020630272 ecap 1000
[    0.037687] DMAR: RMRR base: 0x000000000ed000 end: 0x000000000effff
[    0.037690] DMAR: RMRR base: 0x000000bf7ed000 end: 0x000000bf7fffff
[    0.037692] DMAR: No ATSR found
[    0.794833] IOMMU 0xfed93000: using Register based invalidation
[    0.794837] IOMMU: Setting RMRR:
[    0.794857] IOMMU: Setting identity map for device 0000:00:1d.0 [0xbf7ed000 - 0xbf800000]
[    0.794935] IOMMU: Setting identity map for device 0000:00:1a.0 [0xbf7ed000 - 0xbf800000]
[    0.794980] IOMMU: Setting identity map for device 0000:00:1d.0 [0xed000 - 0xf0000]
[    0.795011] IOMMU: Setting identity map for device 0000:00:1a.0 [0xed000 - 0xf0000]
[    0.795041] IOMMU: Prepare 0-16MiB unity mapping for LPC
[    0.795059] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0x1000000]

Code: Alles auswählen

lspci
...
05:00.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
...

Code: Alles auswählen

lspci -v
...
05:00.0 Ethernet controller: D-Link System Inc RTL8139 Ethernet (rev 10)
        Subsystem: D-Link System Inc DFE-538TX 10/100 Ethernet Adapter
        Flags: bus master, medium devsel, latency 64, IRQ 20
        I/O ports at e800 [size=256]
        Memory at fbfffc00 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2
        Kernel driver in use: 8139too
...

Code: Alles auswählen

lsmod | grep 8139too
8139too                26385  0
mii                    12675  1 8139too

Code: Alles auswählen

virsh nodedev-dumpxml pci_0000_05_00_0
<device>
  <name>pci_0000_05_00_0</name>
  <parent>pci_0000_00_1e_0</parent>
  <driver>
    <name>8139too</name>
  </driver>
  <capability type='pci'>
    <domain>0</domain>
    <bus>5</bus>
    <slot>0</slot>
    <function>0</function>
    <product id='0x1300'>RTL8139 Ethernet</product>
    <vendor id='0x1186'>D-Link System Inc</vendor>
    <capability type='virt_functions'>
    </capability>
  </capability>
</device>

Installation einer virtuellen Maschine mithilfe eines PXE-Servers:

Code: Alles auswählen

virt-install -n testvm -r 256 --vcpus=1 --os-variant=debiansqueeze --accelerate -v -w bridge:br0,model=virtio --vnc --vncport=5901 --noautoconsole -f /home/serveradmin/testvm.qcow2 -s 10 --pxe

PCI-Karte der VM bekanntmachen:

Code: Alles auswählen

virsh edit testvm
...
  <devices>
	...
	<hostdev mode='subsystem' type='pci' managed='yes'>
      <source>
        <address domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
      </source>
    </hostdev>
  </devices>
...

Die vollständige XML-Datei der VM gibts hier 36233

Netzwerkkarte vom System trennen:

Code: Alles auswählen

virsh nodedev-dettach pci_0000_05_00_0

Treiber prüfen:

Code: Alles auswählen

readlink /sys/bus/pci/devices/0000\:05\:00.0/driver
../../../../bus/pci/drivers/pci-stub

VM starten:

Code: Alles auswählen

virsh start testvm

Fehlermeldung:

Code: Alles auswählen

error: Failed to start domain testvm
error: internal error Process exited while reading console log output: char device redirected to /dev/pts/1
Unable to assign device: PCI region 1 at address 0xfbfffc00 has size 0x100,  which is not a multiple of 4K
Error initializing device pci-assign

Protokoll unter /var/log/libvirt/qemu/testvm.log

Code: Alles auswählen

2012-02-07 08:02:05.187+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 256 -smp 1,sockets=1,cores=1,threads=1 -name testvm -uuid b7df9706-2763-edb7-4347-cb1d33283ab9 -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/testvm.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc -boot c -drive file=/dev/vmpool/testvm,if=none,id=drive-virtio-disk0,boot=on,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:05:0c:e4,bus=pci.0,addr=0x3 -net tap,fd=27,vlan=0,name=hostnet0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:11 -k de -vga cirrus -device pci-assign,host=05:00.0,id=hostdev0,bus=pci.0,addr=0x6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
Domain id=16 is tainted: high-privileges
char device redirected to /dev/pts/1
Unable to assign device: PCI region 1 at address 0xfbfffc00 has size 0x100,  which is not a multiple of 4K
Error initializing device pci-assign
2012-02-07 08:02:05.439+0000: shutting down

Gibt es hier einen Ausweg oder hat jemand eine ähnliche Konfiguration laufen und könnte mich hier evtl. ein bißchen unterstützen?

Gruß,
David

[schorsch_76]

Das wichtigste was bei PCI Passthrough nötig ist, ist, dass das Chipset eine IO-MMU hat. Bei Intel sollte VT-d aktiviert sein. Prüfe mal dmesg was das zu IO-MMU zu sagen hat

Gruß
schorsch

[vitaminb]

Hallo schorsch,

das hast Du evtl. überlesen, IOMMU ist aktiv:

Code: Alles auswählen

dmesg | grep -e DMAR -e IOMMU
[    0.000000] ACPI: DMAR 00000000bf7b00f0 00090 (v01    AMI  OEMDMAR 00000001 MSFT 00000097)
[    0.000000] Intel-IOMMU: enabled
[    0.037674] DMAR: Host address width 36
[    0.037677] DMAR: DRHD base: 0x000000fed93000 flags: 0x1
[    0.037684] IOMMU fed93000: ver 1:0 cap c9008020630272 ecap 1000
[    0.037687] DMAR: RMRR base: 0x000000000ed000 end: 0x000000000effff
[    0.037690] DMAR: RMRR base: 0x000000bf7ed000 end: 0x000000bf7fffff
[    0.037692] DMAR: No ATSR found
[    0.794833] IOMMU 0xfed93000: using Register based invalidation
[    0.794837] IOMMU: Setting RMRR:
[    0.794857] IOMMU: Setting identity map for device 0000:00:1d.0 [0xbf7ed000 - 0xbf800000]
[    0.794935] IOMMU: Setting identity map for device 0000:00:1a.0 [0xbf7ed000 - 0xbf800000]
[    0.794980] IOMMU: Setting identity map for device 0000:00:1d.0 [0xed000 - 0xf0000]
[    0.795011] IOMMU: Setting identity map for device 0000:00:1a.0 [0xed000 - 0xf0000]
[    0.795041] IOMMU: Prepare 0-16MiB unity mapping for LPC
[    0.795059] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0x1000000]

Dazu habe ich unter /etc/default/grub die Variable GRUB_CMDLINE_LINUX_DEFAULT wie folgt angepasst:

Code: Alles auswählen

...
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"
...

Bis auf das manuelle Erstellen des Kernels habe ich ziemlich viel von http://www.linux-kvm.org/page/How_to_as ... T-d_in_KVM abgeguckt und probiert. Den Kernel neu zu kompilieren finde ich ziemlich aufwendig - ist das denn unbedingt nötig oder bietet der Standard-Kernel alle drei notwendigen Features?

• set "Bus options (PCI etc.)" -> "Support for DMA Remapping Devices" to "*"
• set "Bus options (PCI etc.)" -> "Enable DMA Remapping Devices" to "*"
• set "Bus options (PCI etc.)" -> "PCI Stub driver" to "*"

Im Bios sind neben VT-d alle Virtualisierungsoptionen aktiviert ... wie die alle namentlich lauten weiß ich gerade nicht.




Gruß

[schorsch_76]

[1] und [2] hab ich hierfür noch gefunden. Es geht hierbei zwar um eine TV Karte, aber das sollte ja nicht interessieren.

Gruß
schorsch

[1] http://www.hevelmann.de/2011/10/durchge ... ssthrough/
[2] http://forum.proxmox.com/threads/7534-P ... ng-support

[vitaminb]

Anleitung Nr. 1 kannte ich bereits und bringt leider nicht den gewünschten Erfolg. Beim Starten der VM taucht wieder bzw. immer noch der genannte Fehler auf:

Code: Alles auswählen

 virsh start testvm
error: Failed to start domain testvm
error: internal error Process exited while reading console log output: char device redirected to /dev/pts/1
Unable to assign device: PCI region 1 at address 0xfbfffc00 has size 0x100,  which is not a multiple of 4K
Error initializing device pci-assign

Die Kernel-Optionen scheinen teilweise aktiviert zu sein:

Code: Alles auswählen

grep "DMAR" /boot/config-2.6.32-5-amd64
CONFIG_DMAR=y
# CONFIG_DMAR_DEFAULT_ON is not set
CONFIG_DMAR_FLOPPY_WA=y

Kann man CONFIG_DMAR_DEFAULT_ON nachträglich und ohne den Kernel neu zu kompilieren aktivieren?

[schorsch_76]

...Kann man CONFIG_DMAR_DEFAULT_ON nachträglich und ohne den Kernel neu zu kompilieren aktivieren?

Nein .. Solche Kernel Optionen lassen sich nur via Kernel Neukompilierung ändern. Ist aber kein Hexenwerk
Gruß
schorsch

[vitaminb]

Also ich habe jetzt nach der Anleitung von http://wiki.linuxmce.org/index.php/Inst ... ne_via_KVM die notwendigen Optionen gesetzt und den Kernel 2.6.32-5 neu gebaut.

Der Kernel bootet ohne Probleme und wird auch vom System erkannt:

Code: Alles auswählen

uname -r
2.6.32.5-iommu

Code: Alles auswählen

grep "DMAR" /boot/config-2.6.32.5-iommu
CONFIG_DMAR=y
CONFIG_DMAR_DEFAULT_ON=y
CONFIG_DMAR_FLOPPY_WA=y

Code: Alles auswählen

dmesg | grep -e DMAR -e IOMMU
[    0.000000] ACPI: DMAR 00000000bf7b00f0 00090 (v01    AMI  OEMDMAR 00000001 MSFT 00000097)
[    0.000000] Intel-IOMMU: enabled
[    0.039424] DMAR: Host address width 36
[    0.039428] DMAR: DRHD base: 0x000000fed93000 flags: 0x1
[    0.039434] IOMMU fed93000: ver 1:0 cap c9008020630272 ecap 1000
[    0.039437] DMAR: RMRR base: 0x000000000ed000 end: 0x000000000effff
[    0.039440] DMAR: RMRR base: 0x000000bf7ed000 end: 0x000000bf7fffff
[    0.039443] DMAR: No ATSR found
[    0.727912] IOMMU 0xfed93000: using Register based invalidation
[    0.727917] IOMMU: Setting RMRR:
[    0.727937] IOMMU: Setting identity map for device 0000:00:1d.0 [0xbf7ed000 - 0xbf800000]
[    0.728016] IOMMU: Setting identity map for device 0000:00:1a.0 [0xbf7ed000 - 0xbf800000]
[    0.728061] IOMMU: Setting identity map for device 0000:00:1d.0 [0xed000 - 0xf0000]
[    0.728092] IOMMU: Setting identity map for device 0000:00:1a.0 [0xed000 - 0xf0000]
[    0.728122] IOMMU: Prepare 0-16MiB unity mapping for LPC
[    0.728140] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0x1000000]

ABER ... das Problem besteht leider nach wie vor

Was könnte denn evtl. noch die Ursache sein?

[vitaminb]

Ich bin mittlerweile etwas weitergekommen.

Probeweise habe ich die Netzwerkkarte entfernt und einen LSI Raid-Controller in einen PCIe-Steckplatz gesteckt. Gebootet mit dem selbstgebauten Kernel 2.6.32.5-iommu kann ich die Karte vom Host abzwacken und an eine VM durchreichen. Diese bleibt aber beim Booten nach der Grub-Anzeige eine Weile stehen bis sie letztendlich komplett hochgefahren ist. In der VM taucht lt. lspci der Controller auf was schon einmal ein gutes Zeichen ist ... die Host-Logdatei zeigt hier aber eher weniger erfreuliches:

Code: Alles auswählen

2012-02-07 17:47:58.585+0000: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/ QEMU_AUDIO_DRV=none /usr/bin/kvm -S -M pc-0.12 -enable-kvm -m 256 -smp 1,sockets=1,cores=1,threads=1 -name testvm -uuid b7df9706-2763-edb7-4347-cb1d33283ab9 -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/testvm.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc -boot c -drive file=/dev/vmpool/testvm,if=none,id=drive-virtio-disk0,boot=on,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -device virtio-net-pci,vlan=0,id=net0,mac=52:54:00:05:0c:e4,bus=pci.0,addr=0x3 -net tap,fd=19,vlan=0,name=hostnet0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -usb -device usb-tablet,id=input0 -vnc 127.0.0.1:11 -k de -vga cirrus -device pci-assign,host=01:00.0,id=hostdev0,bus=pci.0,addr=0x6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
char device redirected to /dev/pts/2
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?
Failed to assign irq for "hostdev0": Operation not permitted
Perhaps you are assigning a device that shares an IRQ with another device?

Die lspci-Ausgabe reiche ich noch nach - mir kam eben etwas anderes dazwischen.

[schorsch_76]

Denke dass du das durchgereichte Gerät am Host blacklisten must.
Gruß
schorsch

[vitaminb]

Daran habe ich gedacht und den Controller (Modul megaraid_sas) in einer separaten Blacklist eingetragen:

Code: Alles auswählen

cat /etc/modprobe.d/lsiraid.conf
blacklist megaraid_sas

Anschließend wurde das initramfs neu geschrieben:

update-initramfs -u -k all

Ich bekomme die nächsten Tage etwas neue Hardware dann werde ich mich mit dem Thema weiter beschäftigen und das Ganze nochmal probieren.

Wäre ja gelacht wenn das nicht irgendwie klappen würde