[gelöst]Jessie:KVM full virtualization PCI-Passthrough error

[matman]

Auf Wheezy lief alls schön sauber. Aber nun, mit den Startskripten etc. auf Jessie umgezogen, will qemu-kvm nicht mehr starten, wenn ich PCI-Karten durchreichen will (per vfio). Ohne PCI-Passthrough läuft kvm.

Nachfolgend die Ausgabe vom stdout. Vielleicht hat jemand eine Idee was da los sein könnte?

Code: Alles auswählen

qemu-system-x86_64: vfio_dma_map(0x7f7e6b857c80, 0xc0000, 0x8000, 0x7f7dfc0c0000) = -12 (Cannot allocate memory)
qemu: hardware error: vfio: DMA mapping failed, unable to continue
CPU #0:
EAX=80000033 EBX=80000090 ECX=00000033 EDX=00000cfd
ESI=00000001 EDI=00000090 EBP=00000097 ESP=00006f94
EIP=ffff123e EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
SS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
DS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
FS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
GS =0010 00000000 ffffffff 00c09300 DPL=0 DS   [-WA]
LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
GDT=     000f6be8 00000037
IDT=     000f6c26 00000000
CR0=60000011 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
CPU #1:
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00100f42
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
CPU #2:
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00100f42
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
CPU #3:
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00100f42
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 0000ffff 00009300
CS =f000 ffff0000 0000ffff 00009b00
SS =0000 00000000 0000ffff 00009300
DS =0000 00000000 0000ffff 00009300
FS =0000 00000000 0000ffff 00009300
GS =0000 00000000 0000ffff 00009300
LDT=0000 00000000 0000ffff 00008200
TR =0000 00000000 0000ffff 00008b00
GDT=     00000000 0000ffff
IDT=     00000000 0000ffff
CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000000
FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=00000000000000000000000000000000 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000

[NAB]

Also hier ist der Patch, der diese Fehlermeldung einführt:
https://lists.nongnu.org/archive/html/q ... 01966.html
vom Januar 2014. So richtig schlau werde ich allerdings nicht daraus ... da steht, es ginge vorallem um fehlende Privilegien des aufrufenden Benutzers. Das scheint kein Hardware-Fehler zu sein.

Mal blöd gefragt ... geht's denn als "root"?

[matman]

Ja, in der Tat, als root geht es.

Was macht man da denn nun am besten? Kann man die Privilegien passend basteln? Oder lieber eine neuere Version von qemu-kvm benutzen? Letzteres musste ich bisher eh immer machen. Aber wäre ja mal schön, wenn ich endlich einfach die deb Pakete nutzen könnte, ohne bei jedem neuen Debian da wieder tagelang dran herum fummeln zu müssen.

Und die VM's als root zu betreiben ist denke ich auch keine gute Idee, oder?

[NAB]

Gute Frage ... ich benutze den virt-manager, der kümmert sich automatisch um die passenden Rechte. Wo's bei dir genau klemmt, weiß ich somit auch nicht. Ich denke nicht, dass eine neuere Version von quemu dir da hilft ... das sind ja Probleme mit Zugriffsrechten.

Schau mal unter /dev/vfio ... dein Benutzer muss da Zugriff haben, sonst kann er das durchgereichte Gerät nicht übernehmen.

[matman]

Die Rechte von /dev/vfio sind:

Code: Alles auswählen

crw-rw-rwT root root

Ich habe eben mal zum Test sowohl den das Skript aufrufenden User, als auch den User mit dem die VM dann laufen soll, zur Gruppe root hinzugefügt. Das bringt aber keine Änderung.

Mal sehen, ob ich per Google noch ne Lösung finde.

Irgendwo hatte ich gestern schon beim Googeln im englisch sprachigen Raum was gefunden. Da war die Rede davon, man müsse dem User per ulimit mehr RAM oder sowas erlauben. Für eine 2G VM z.B. ulimit -l 2621440. Das war aber für ne andere Distri und hat mir leider nicht geholfen.

[NAB]

Steht in dmesg eigentlich irgendwas Erhellendes, wenn diese Fehlermeldung kommt?

[matman]

Also es scheint da wirklich eine Art von Memory-Begrenzung zu geben. Diese beiden Zeilen gibt dmesg nach Aufruf meines Skriptes aus:

Code: Alles auswählen

[  117.004474] vfio-pci 0000:07:00.0: enabling device (0400 -> 0402)
[  119.203401] vfio_pin_pages: RLIMIT_MEMLOCK (65536) exceeded

Das Skript ist übrigens jenes:

Code: Alles auswählen

#!/bin/sh

hwMemory="1024M"

if [ $1 ]; then

        if [ $1 = "himem" ]; then
                hwMemory="2048M"; fi
        if [ $1 = "himem2" ]; then
                hwMemory="4096M"; fi
        fi

echo "Starting kvm with real memory of $hwMemory"

sudo qemu-system-x86_64 \
-no-frame \
-machine type=pc-q35-2.0,accel=kvm \
-cpu host,-svm \
-smp 4,sockets=1,cores=4,threads=1 \
-m $hwMemory \
-name 'Internet Debian Jessie Test' \
-vga vmware \
-k de \
-rtc base=utc,clock=vm \
-usb -usbdevice tablet \
-net none \
-device virtio-scsi-pci,id=scsi \
-drive file=/dev/dm-3,id=disk0,snapshot=off,cache=writethrough,format=raw \
-device scsi-hd,drive=disk0 \
-boot c \
-device vfio-pci,host=07:00.0,bus=pcie.0 \
-chroot /home/kvmuser \
-runas kvmuser

[NAB]

Uhm ... ich habe noch nie ein qemu im chroot gesehen ... ich habe keine Ahnung, wie sich das verhält. Eigentlich müsstest du ja auch /sys und /dev ins chroot mounten, damit qemu darauf Zugriff hat. Ich würd mal testen, ob's ohne chroot läuft.

Aber der Meldung im dmesg nach bist du mit ulimit auf der richigen Spur. Ich habe dazu das hier gefunden:
http://www.spinics.net/lists/kvm/msg73894.html
und 64 KB klingt in der Tat etwas mager.

[matman]

kvm -chroot /home/kvmuser bewirkt soweit ich weiß einfach nur, das die VM dann /home/kvmuser als Heimatverzeichnis hat. Ohne chroot liefe die VM dann sozusagen im Heimatverzeichnis des Users, der das Skript startet. Also auch kein root. Aber diese Sperre wegen des Limits betrifft ja alle non-root User, wenn ich das richtig verstanden habe.

Ich hatte das Skript einst extra so geschrieben, das nicht der normale User, sondern ein spezieller für die VM's zuständig ist. Mag vielleicht etwas paranoid sein. Aber sicher ist sicher. Und was mit nicht allzuviel Umstand möglich ist sollte man machen, finde ich.

Ich könnte die VM zur Not auch einfach per sudo als root laufen lassen. Starten lässt sich qemu-kvm eh nur als Superuser, darum auch das sudo in meinem Skript und am Ende -runas kvmuser, um die VM nicht permanent mit Root-Rechnten am Laufen zu haben. Und ich weiß nicht so recht, ob das eine gute Idee ist, die VM ständig als root zu betreiben. Besonders relevant wären für mich die Fragen: was wäre, wenn jemand per Netzwerk auf die VM Zugriff bekommt? Und wie hoch ist dann das Risiko, das man von dort auf den Host zugreifen kann? Wenn letzteres unmöglich ist, könnte ich die VM denke ich auch bedenkenlos als root laufen lassen. Aber ein User sepziell für die VM's wäre mit trotzdem irgendwie lieber

Wie wendet man denn dieses ulimit -l an? Das habe ich leider noch nicht kapiert. Theoretisch müsste das ja die Lösung sein.

[NAB]

Aber diese Sperre wegen des Limits betrifft ja alle non-root User, wenn ich das richtig verstanden habe.

Hast du das denn ausprobiert? Also ohne chroot? Das wechselt nämlich nicht einfach so das Verzeichnis ... dafür wäre ein "cd" am Anfang des Scriptes ausreichend. In der man page steht was von chroot ... und ich kann nicht abschätzen, welche Auswirkungen das auf pci-passthrough haben könnte. Meineswissens muss dazu Zugriff auf /dev/vfio bestehen ... und das wird durch ein chroot ausgeblendet.

Und ja, ich verstehe deine Sicherheitsbedenken ... aber ein "runas" wär mir schon sicher genug.

Ich hab mal bei mir nachgeguckt ... die rechte von /dev/vfio sehen so aus: drwxr-xr-x root:root
Was du gepostet hast, müssen die Rechte von /dev/vfio/vfio gewesen sein, also die Rechte der Kontrolldatei.
Außerdem müsste noch eine Datei /dev/vfio/1 bestehen, in der das durchzureichende Gerät liegt.

Ich kann bei mir beobachten, wie virt-manager die Rechte der benötigten Dateien auf libvirt-qemu:libvirt-qemu ändert bevor es die VM startet - um die VM dann als libvirt-qemu ausführen zu können, und nicht als root.

Und ich krieg's auch nicht hin, per ulimit -l das Limit für Memlock zu ändern. Das betrifft nur die aktuelle Shell und geht nur als root und hat keine Auswirkungen auf die Prozesse anderer User.

Die einzige Methode, die ich gefunden habe, ist ein Eintrag in /etc/security/limits.conf
Zeilen wie:
user1 hard memlock unlimited
user1 soft memlock unlimited
müssten das Limit beseitigen.
Überprüfen kann "user1" das dann mit "ulimit -l".

[matman]

Ja ich habe es gestern abend dann auch einmal ohne -chroot probiert. Das ändert aber leider nichts. Laut meinen Infos macht die Option -chroot nichts anderes als das Kommando cd, so jedenfalls steht es im Qemu-Buch (zeimlich weit unten im Abschnitt Debugging/Experten-Optionen:

-chroot dir

Beim Start der Instanz wird mit chroot in das angegebene Verzeichnis gewechselt. Diese Option ist nützlich in Kombination mit der Option -runas.

-runas user

Beim Start der Instanz wird der Prozess dem angegebenen Benutzer übereignet. Dies unterstützt eine Erhöhung der Sicherheit.

Sorry, die von mir geposteten Rechte zu /dev/vfio stammen von Wheezy. Ich habe auf Jessie noch keinen Browser etc. installiert, arbeite also noch mit Wheezy und hoffte da gibt es zu Jessie keinen Unterschied.

Die Rechte zu ändern hatte ich auch schon überlegt. Ich hatte da zwar Sicherheitsbedenken. Aber wenn virt-manager das auch tut, dann kann ich das wohl machen.

Und das mit ulimit ist mir nach wie vor ein Rätsel. Du hattest ja weiter oben eine englische Seite verlinkt. Dort steht auch was von /etc/security/limits.conf und darum experimentierte ich gestern noch ne ziemlich lange Weile damit herum. Beispielweise mit folgendem Eintrag:

Code: Alles auswählen

kvmuser hard memlock unlimited

Und anstatt unlimited probierte ich auch mit Werden wie z.B. 4500000 herum. Und um sicher zu gehen, das diese Konfigration auch wirklich akriv ist habe ich sogar nach jeder Änderung in der /etc/security/limits.conf das System rebootet. Aber irgendwie hatte das alles keinen Effekt und qemu-kvm beschwerte sich trotzdem immer wieder über das 64k Memlock-Limit. Keine Ahnung warum. Möglicherweise wegen fehlender Rechte zu /dev/vfio, das könnte natürlich sein.

Ich werde jetzt als nächstes mal sehen, ob es klappt, wenn ich mich an den Vorschlag im von dir geposteten Artikel ( Re: vfio problem halte. Nicht alles werde ich übernehmen. Denn ich würde gerne auf zusätzliche Software verzichten, solange es irgendwie möglich ist eine VM direkt per qemu-kvm zu starten. Aber vielleicht verhält sich das System ja anders, wenn ich per su user -c starte anstelle von sudo. Und ansonsten sind da ja noch die Benutzerrechte, die ich auf den kvm User setzten kann. Ich hoffe ich bekomme das heute hin.

Ist mal wieder alles komplizierter als vorher gedacht. Aber was solls? Selbst mit Virtualbox war es bisher immer ein Krampf, wenn man die VM's per separaten User starten wollte. Da schlag ich mich lieber mit KVM rum

[NAB]

Das Problem ist, dass deine "RLIMIT_MEMLOCK" Meldung halt ausgesprochen selten ist ... ich werd da auch nicht schlau draus, und Hinweise darauf sind rar und deuten meistens auf Probleme beim VGA-Passsthrough hin, welches dann auch als "root" scheitert. Bei dir hingegen klappt es als "root", es dürfte also irgendeine Art von Berechtigungsproblem sein.

Ich hab hier noch was Interessantes gefunden:
https://bbs.archlinux.org/viewtopic.php?id=162768&p=70
Posting #1750 von siddharta
Wenn er qemu als root startet, funktioniert alles. Wenn er es per libvirt als User startet, kriegt er eben jene "RLIMIT_MEMLOCK"-Meldung, obwohl libvirt qemu als root startet. Aus irgendeinem bescheuerten Grund reicht er unter libvirt aber nur die Grafikkarte durch und nicht die zugehörige Soundkarte.
(Beachte die lange Liste an Geräten, die er unter die Kontrolle von libvirt stellt, inklusive "/dev/vfio/vfio",
"/dev/vfio/1" und "/dev/kvm")
Auf der nächsten Seite:
https://bbs.archlinux.org/viewtopic.php?id=162768&p=71
Posting #1753
fügt er hinzu, dass eine Erhöhung des Memlock nicht geholfen hat.
Die Antwort von aw (dem Erfinder von vfio) in Posting #1756 ist leider sehr knapp: entweder libvirt als root laufen lassen (das wussten wir schon vorher) oder libvirt klar machen, dass es vfio-passthrough beherrschen muss. Aha? Libvirt muss sich also besondere Zusatzkräfte besorgen, um selber den Memlock erhöhen zu können, obwohl es qemu als root laufen lässt?

Ich vermute, das gilt auch für dich. Probiere mal folgende Zeilen in der limits.conf:
* hard memlock unlimited
* soft memlock unlimited
Das sollte den Memlock für alle User auf "unlimited" setzen. Überprüfen kannst du das dann mit "ulimit -l" - sowohl für den User, der das sudo-Script ausführt als auch für den User, zu dem dann gewechselt wird. Einschränken kannst du die Rechte später immer noch.

Und nein, auch im Qemu Buch steht, dass ein chroot ausgeführt wird. Ein chroot ist was anderes als ein cd. Probiere es doch mal selber aus und mache ein chroot in das entsprechende Verzeichnis. /dev ist dann nicht mehr erreichbar.

[matman]

Hach ja, manchmal sieht man den Wald vor lauter Bäumen nicht mehr. Hast ja Recht, das steht tatsächlich, das kvm dann mit chroot in das definierte Verzeichnis startet.

Aber wie ich schon meinte: auch ohne -chroot kommt die immer selbe Fehlermeldung.

Das mit der limits.conf ist auch irgendwie schon fast wie verhext. Im alten Wheezy habe ich schon die ganze Zeit die Gruppe audio mit unlimited konfiguriert. Und zwar wegen Ardour. Das betrifft dann auch den normalen sowie den kvm User. Vielleicht läuft das Skript ja darum auf meinem alten System.

Mit Jessie dagegen kann ich im Moment echt machen was ich will. Das System verhält sich so, als hätte ich da nie etwas in die limits.conf eingetragen. Ich kann ja gleich noch einmal * hard memlock unlimited ausprobieren. Aber mir scheint da sehr, irgendwie will meine Jessie-Installation noch nicht so recht mit der Datei limits.conf warm werden. Vielleicht fehlt noch ein wichtiges Tool.

Ich habe im Moment nur das Basis-System, Xorg, Gnome 3 und qemu-kvm installiert. Ich glaube es ist das beste, ich hau als nächstes erstmal die ganze Software drauf, die ich so brauche. Da werden dann erfahrungsgemäß noch diverse tools, libs und daemons wegen der ganzen Paketabhängigkeiten mit installiert. Dadirch werden manchmal auch System-Problemchen behoben. Ich hoffe mal, das hilft irgendwie ein wenig.

[NAB]

hmmm ... die limits.conf wird ja über pam abgearbeitet:

Code: Alles auswählen

cat /etc/pam.d/login | grep limits
# set access limits.
# Sets up user limits according to /etc/security/limits.conf
# (Replaces the use of /etc/limits in old login)
session    required   pam_limits.so

Die letzte Zeile müsste sich bei dir auch finden lassen.

Eigentlich müsste es eine Methode geben, diese Limits im laufenden Betrieb für bestimmte User zu erhöhen ... ich finde dazu nur nichts

[matman]

Bingo! Endlich habe ich es geschafft

Manchmal kann es helfen, wenn man einfach mal was anderes macht. Die ganze Software-Installation führte nämlich nicht zur Lösung. Aber dafür ist das mal jetzt auch erledigt und plötzlich kam mir die Idee mal nach "howto /etc/security/limits.conf zu googeln und ich fand u.a. das hier:

http://serverfault.com/questions/544171 ... be-ignored

Dort fand ich zwar nicht die Lösung, hatte aber einen neuen Blickwinkel auf die Angelegenheit und plötzlich ging mir ein Licht auf.

Die Problematik dieses Falles, hängt soweit ich das jetzt überblicke, mit einigen Änderungen der Limits von Wheezy zu Jessie zusammen. Bei Wheezy genügte ein simples:

Code: Alles auswählen

user memlock unlimited

Um den selben Effekt mit Jessie hinzubekommen braucht es nun:

Code: Alles auswählen

user hard memlock unlimited
user soft memlock unlimited

Statt unlimited gehen wohl aiuch konkrete numerische Werte. Aber anscheinend braucht man beide Zeilen, also hard und soft. Nachdem ich die Manpage zur limits.conf las ging ich davon aus, man braucht soft, wenn auch normale User den Wert ändern dürfen und wenn nur root das darf nimmt man hard. Aber naja... ich verstehe englisch zwar ganz gut, aber Irrtümer sind da nicht ausgeschlossen

Gibt man beises an (hard & soft), dann jedenfalls geht es.

Dein Vorschlag in diese Richtung vorhin war also sehr gut

Und danke für deine Mühe.

[NAB]

Also der Sinn des "soft limits" erschließt sich mir auch nicht ... aber da beide per Default auf 64 eingestellt sind, war mir klar, dass man beide erhöhen sollte. Aber Hauptsache es geht jetzt

Nur mal aus Neugierde: läuft das jetzt mit "chroot"?