Durchgereicht: PCI passthrough bei Xen 3.2rc

Update, 17. Januar 2008: Xen 3.2 final wurde heute veröffentlicht. Golem berichtet darüber.

Ein großes Problem bei vielen Virtualisierungstechnologien ist die fehlende Möglichkeit, in einem Gastsystem “rohen” Zugriff auf einzelne Hardwarekomponenten zu erhalten. Zwar bieten VMware und andere das Durchreichen von USB-Geräten, doch das ist eine Lösung, die für physikalisch vom Netz des Wirts getrennte Firewalls oder RAID-Subsysteme nicht wirklich akzeptabel ist. Eine interessante Abhilfe bietet Xen, wo mit vertretbarem Aufwand Gäste direkten Zugriff auf PCI-Karten bekommen.

Anpassungen am Dom0-Kernel

Der Dom0-Kernel sollte in der Regel richtig konfiguriert sein. Hier muss unter “Xen” der “PCI-device backend driver” aktiviert sein und dessen Modus auf “Passthrough” stehen.

Anpassungen am DomU-Kernel

In vielen Fällen werden Sie einen eigenen DomU-Kernel benötigen. Die von mir und einigen anderen angebotenen DomU-Kernel integrieren nur die Frontend-Treiber für Xen-Block-Devices und Xen-Network-Devices, Sie benötigen jedoch einen Kernel, der einerseits den PCI-Frontend-Treiber mitbringt und andererseits Treiber für die zu unterstützenden Geräte. Als Ausgangsbasis können Sie einen normalen XenU-Kernel verwenden und die gewünschten Treiber zusätzlich auswählen:

Stillegen der PCI-Devices in der Dom0

Damit einzelne PCI-Geräte durchgereicht werden können, müssen diese per Bootparameter stillgelegt werden. Identifizieren Sie zunächst mit lspci -v die betreffenden Karten und ergänzen Sie dann die Appendzeile der Dom0:

title Xen 3.2.0rc4 - Linux 2.6.18.8
root (hd0,0)
kernel /boot/xen-3.2.0-rc4-pre.gz
module /boot/vmlinuz-2.6.18.8-xen0 root=/dev/hda1 ro pciback.permissive pciback.hide=(00:0c.0)(00:0c.1)(00:0c.2)(00:0d.0)(00:09.0)
boot

Nun ist ein Reboot des gesamten Systems erforderlich. Anschließend können Sie in der DomU mit lspci die durchgereichten Karten ermitteln, Treiber laden und so die Hardware direkt verwenden:

00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:0c.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
00:0c.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 61)
00:0c.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 63)
00:0d.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)

Anmerkungen:

Der hier zu sehende Gast war ein temporär aufgesetztes Testsystem mit einer Hauppauge DVB-C-Karte, der die Möglichkeit haben sollte, Videoaufnahmen zu machen, ohne dass Änderungen an der Dom0 erforderlich sind, und der via direktem USB-Zugriff diese Videos flott auf USB-Festplatten kopieren sollte. Hierfür kam ein als PCI-Steckkarte ausgeführter USB-Controller zum Einsatz. Ob es möglich ist, einzelne Roothubs dieses Controllers (immerhin werden diese als separate Geräte angezeigt) durchzureichen, habe ich nicht ausprobiert.

Nach meinem bisherigen Kenntnisstand funktioniert das PCI passthrough nicht bei Domains im Full Virtualization Mode. DomUs haben Kenntnis über die Speicheraufteilung und können demnach Adressen richtig zuordnen. Full Virtualization Mode Clients sehen dagegen Speicher ab 0 Byte.

Ich habe noch keine Performancetests von SATA-Controllern, die via Xen-Block freigegeben wurden, gegenüber dem Durchreichen dieser Controller durchgeführt. Allerdings sollte die Performance spürbar besser ausfallen, da der Weg über den Blockdevice-Treiber der Dom0 wegfällt.

Theoretisch sollte es möglich sein, auch von einer durchgereichten SATA-Karte zu booten. Damit verliert man aber einen der größten Vorteile von Xen, die weitgehende Abstraktion von der darunterliegenden Hardware. In Einzelfällen, in denen Performance vor Abstraktion geht, dürfte es ein guter Kompromiss sein, das Grundsystem von einem kleinen Image zu starten und dann die Datenverzeichnisse, auf denen Performance benötigt wird, via passthrough anzusprechen.

Der Screenshot des domU-Kernels entstand mit dem openSUSE-10.3-Kernel auf einer Ubuntu-7.10-domU. Eine etwas exotische Konfiguration, aber openSUSE liefert recht aktuelle Distributionskernel mit sauber integrierten Xen-Patches. In diesem Fall war ein Kernel >2.6.19 erforderlich, um die DVB-Treiber aus dem Mercurial-Repository integrieren zu können.

5 thoughts on “Durchgereicht: PCI passthrough bei Xen 3.2rc

  1. fritz tafill

    Hi,

    nehme an es handelt sich um “domU-Kernels entstand mit dem openSUSE-10.3-Kernel auf einer Ubuntu-7.10-dom0″ und nicht 2 domU Instanzen.

    Vielen Dank für den Beitrag. Stehe auch vor dem Problem mit dem Mercurial-Repository. Überlege aber ob ich noch warten soll bis der in den Kernel integrierte Hypervisor passthrough unterstützt. Dann wäre man die xen kernel Abhängigkeit zumindest auf guest Seite los.

    Gruß
    Fritz

  2. Mattias

    Nein, ich habe in der Tat aus openSUSE-Kernelsourcen einen domU-Kernel gebaut, den ich in meiner Ubuntu-domU einsetze. Die dom0 ist ebenfalls Ubuntu, verwendet aber den “Xen-Vanilla” 2.6.18 aus dem Mercurial.

  3. fritz tafill

    Ok,
    habs jetzt verstanden.
    Bin ziemlich beeindruckt. Wäre nie auf die Idee gekommen das so anzugehen!
    Gruß
    Fritz

  4. Thomas

    Hallo,

    habe mit großem Interesse den Beitrag gelesen. Verwende als Basissystem Ubuntu Gutsy mit dem 2.6.22-14-xen Kernel aus den Paketen. Leider wird pciback.hide nicht so unterstützt wie es sein soll (moechte eine AVM Fritz einer DomU zur Verfügung stellen). Stehe daher vor dem Problem dass ich den Kernel neu machen muss. Dachte mir, dann kannste auch direkt auf 3.0.2 gehen. Leider verstehe ich nicht wie ich dann aber den openSUSE Kernel einbinden soll?! Folgendes Vorgehen :

    wget http://bits.xensource.com/oss-xen/release/3.2.0/xen-3.2.0.tar.gz
    tar xzfv xen-3.2.0.tar.gz
    hg clone http://xenbits.xensource.com/linux-2.6.18-xen.hg
    cd xen-3.2.0
    make linux-2.6-xen-config CONFIGMODE=menuconfig
    cp /boot/config-2.6.22-14-server build-linux-2.6.18-xen_x86_32/.config
    make linux-2.6-xen-build

    hoffe du kannst mir helfen?

    gruss
    thomas

  5. Rainer

    Hallo,

    hat einer von Euch diesen genialen Trick schon mal auf Citrix XenServer 4.1 oder 5.0 gemacht. Als XEN Version wird 3.2.1 und als Kernel wird 2.6.18-92 usw. ausgegeben. Man hat auch normalen Zugriff auf die Console. Kann man da was machen? Würde mich freuen, wenn Ihr mir ein paar Tips geben könntet!

    DANKE!

    Rainer

Comments are closed.