Xen und 3D

[DragonTEC]

versuch doch mal in der linux vm n debian oder ubuntu standard kernel und n pciback.hide auf die cirrus dann is die doch weg

 

[Bunkasan]

Aber nur pseudo weg. Als Pcigerät wird sie immer noch gelisted und das VBIOS der cirrus als primäres in den Speicher geladen. Genau das ist das Problem. Und um die Cirrus komplett auszuschließen müsste ich den passtrough umbauen...

EDIT: Selbst wenn ich das täte. würde das ATI-VBIOS immer noch als sekundäres und nicht als primäres geladen ohne echten VGA-passtrough. Hast du erfahrung mit zwei Karten in einem normalen Linux? Scheinbar ist das ein generelles Problem des Xservers, die Zweitkarte zu initialisieren.

 

[trikolon]

Hallo alle,
ich verfolge diesen Thread schon eine ganze weile und bin schon ziemlich angetan davon. Allerdings fehlt mir etwas der Einstieg wie ich das vga passthrough ans Laufen kriege. Ich würde sagen, ich kenne mich gut bis sehr gut mit Linux aus (nach 6 Jahren Gentoo sollte man das auch, oder? . Mein Server, um den es geht, hat ein Gigabyte 890FXA-UD5 Mainboard, mit dem ich bereits erfolgreich PCI Geräte an PV und an HVM Domains gereicht habe. Als Distri benutze ich Debian Squeeze mit den Testing debs für Xen und Co.
Ich möchte meine einzige PCI-E VGA Karte an eine Domain durchreichen um es als XBMC VM laufen zu lassen. Wenn ich das alles soweit einstelle in der VM Config, dann lande ich (laut VNC Anzeige) in einer Art QEMU Prompt. Karte ist eine ATI Spphire 5450.
Mit welcher Config läuft das ganze denn? Muss ich zwangsweise auf xen unstable wechseln? Muss ich vom eigentlichen Debian Dom0 Kernel weg und mir einen eigenen bauen oder ist in dem Kernel alles was ich brauche? Xen Testing (also 4.0.2 mein ich) selbst zu bauen und zu installieren wäre kein Problem, will mir aber die Arbeit nur machen, wenn es denn auch damit geht.
Die Patches aus dem xeninstall script für 4.0.2 habe ich soweit eingebaut und das ganze baut auch durch. Allerdings den Kernelpatch habe ich mir bisher gespart.

Eine kleine Liste mit "das brauchst du, damit es klappt" wäre super!
Vielen Dank schonmal.

Gruß Ben
​

 

[Bunkasan]

Tachen,
der "echte" VGA-Passtrough ist bei ATI Karten nur mit der 4.0 stable / testing möglich, und das auch nur mit dem vga.patch von meinem Script. Was Dragontec und ich zur Zeit auf 4.1 unstable betreiben, hat damit eigentlich nicht viel zu tun. Windows kann oder will die emulierte Cirrus Karte nicht starten, und lädt den Desktop auf der durchgereichten Karte. Geht aber deswegen auch nur mit Windows 7.

Für den echten einfach wie gesagt 4.0 stable / testing mit dem patch backen, Karte je nach belieben beim start oder vor VM start vor der dom0 hiden, pci gerät in der config einfügen, gfx_passtrou auf 1 setzen, VM starten. Was anfangs als möglicherweise als fehlschlag interpretiert wird, ist, dass die VM teils erst nach dem kompletten Boot was anzeigt. Am besten den Bootvorgang über "xm dmesg" bzw xentop beobachten.

Der Kernelpatch ist inzwischen obsolet, war nur kurzzeitig nötig um nen compilerror beim Suse 2.6.36 auszubügeln.

Kernel kannst du soweit fast alles nehmen was dom0 support bereitstellt, und deinen anforderungen genügt.

 

[trikolon]

hallo nochmal,
also es hat tatsächlich geklappt. squeeze kernel und xen 4.0.2-rc-irgendwas und ich kann meine karte an eine hvm domain reichen und xbmc rennt richtig schön. bin begeistert!!
allerdings hat debian komische sachen gemacht. python 2.6 wollte das site-packages nicht finden. musste also die path variabele händisch anpassen und menche libs sind nicht unter /usr/lib wo er sie gerne hätte, sondern unter /usr/lib64. hat von euch jemand damit probleme gehabt?

gruß

 

[DragonTEC]

prima das das klappt! hast du das xbmc auf linux oder win basis?

was meinst du mit 4.0.2? is das das testing oder unstable? wär gut für meine doku zu wissen, weil ich derzeit an nem umfangreichen tutorial schreibe..

das mit dem usr/lib sollte eigentlihc kein problem sein, weil lib64 nur n symlink auf lib (oder andersrum, weiß nicht mehr wies bei mir is)..

 

[trikolon]

hast du das xbmc auf linux oder win basis?

linux. ubuntu 10.10 mit den fglrx treibern.

was meinst du mit 4.0.2? is das das testing oder unstable?

das ist das 4.0 testing. unstable wäre 4.1.

das mit dem usr/lib sollte eigentlihc kein problem sein, weil lib64 nur n symlink auf lib (oder andersrum, weiß nicht mehr wies bei mir is)..

ja das dachte ich auch, aber musste händisch sachen wie libxenguest und libxencrtl per smybilschen link nach /usr/lib setzen.. sehr komisch! habe schon so ne vermutung, dass ich da irgendwas zerschossen habe, weil ich teilweise sehr rabiat mir alle dateien die ein "xen" enthalten hatten händisch gelöscht, damit auch ganz sicher kein misch-masch aus von hand installierten und per apt installierten sachen entsteht..
das mit python verwundert mich aber fast noch mehr.

 

[DragonTEC]

vielen dank erstmal für die infos!

sag mal, was mich noch interessiert: benutzt du n selbsterstelltes graka bios (bzw. dein natives graka bios) und wie hast du das eingebunden?

 

[trikolon]

Graka-Bios habe ich gegoogelt, dabei kam folgendes heraus: techPowerUp! :: VGA Bios Collection: Sapphire HD 5450 1024 MB

Und dann einfach die Sachen aus dem xeninstall script händisch ausgeführt um das Bios einzugliedern.

Habe mit XBMC gestern Abend noch etwas rumgespielt und das läuft echt fein. Musste aber 1GB Ram und 2 CPUs (vcpus) zuweisen damit auch mkv Dateien flüssig liefen.
Brauchst du sonst noch Infos über mein System?

Gruß

 

[Romep]

Hey,

ich habe mir kürzlich meinen Server mit Xen virtualisiert und dann gesehen, dass man auch die Grafikkarte weiterreichen kann. Ich möchte den Server jetzt auch als HTPC nutzen, da er eh fast immer läuft.

Ich habe einen i5 mit VT-d und im Bios die entsprechende Option aktiviert. Die GPU auf der CPU habe ich an den pciback Treiber gebunden. Windows 7 kann ich installieren, aber sobald ich den Intel HD Grafiktreiber installiere und reboote, schmiert mir die VM vermutlich beim laden des Treibers immer ab.
Im qemu logfile steht "reset requested in cpu_handle_ioreq" danach wurde die VM neu gestartet. In den restlichen logfiles ist das einzige auffällige in der xend.log: "INFO (pciquirk:92) NO quirks found for PCI device [8086:0042:1462:7636]". Die ID ist von der GPU.

Jemand nen Plan woran es liegen kann? Ich habe ein debian squeeze mit den xen packages und kernel von debian (4.0.1, 2.6.32-5).

mfg Romep

 

[DragonTEC]

puhh, an den debian default packages hab ich mich noch nie versucht, weil die noch nicht so weit sind, als das gfx passthrough funktioniert..

ich würd dir empfehlen, einfach mal statt der debian packages n hg pull vom xen-testing repository zu machen und die version nehmen.. dann die grafikkarte mit pciback.hide als kernel load parameter verstecken und OHNE gfx_passthrough=1 als normale pci karte in die domU config packen.. dann sollte es nach der graka treiber installation problemlos laufen (zumindest unter win7)..

ne anleitung, wie du das testing repository kriegst gibts hier: Xen4.0 - Xen Wiki unter installation from source.. da einfach nur die xen sachen ohne das kernel geraffel machen..

 

[Romep]

Das schöne an den Debian packages ist, dass man keine Ahnung vom Kernel bauen haben muss Dort ist ja auch ein Xen 4.0.1 und Kernel 2.6.32 dabei. Ich habe jetzt versucht den dom0 Kernel und xen unter Ubuntu Server 10.10 zu kompilieren aber der Kernel wirft direkt nach dem start ne panic ....

 

[DragonTEC]

Deshalb sag ich ja, ignorier das kernel bauen.. wenn deine debian versionen vom xen 4.0.1 mit dem debian kernel laufen, tuts das xen testing bestimmt auch..

also nur

cd /usr/src
hg clone http://xenbits.xen.org/xen-4.0-testing.hg
[FONT=verdana][/FONT]cd xen-4.0-testing.hg
make xen
make tools
make stubdom
make install-xen
make install-tools PYTHON_PREFIX_ARG=
make install-stubdom

dann nur die den grup starteintrag anpassen, damit er auch das richtige xen.gz nimmt, und schon sollte das ganze auch ganz ohne neuen kernel laufen

 

[Romep]

Ich habe das jetzt in einer vm gemacht, damit ich die ganzen Paket zum kompilieren nicht in meiner dom0 rumfliegen habe. Was genau macht make install-xxxx? Muss ich da nur das xen.gz kopieren? Ich mache gerade noch ein make dist, aber das kompiliert auch den kernel mit und läuft gerade noch.

edit: In dem dist dir ist dann zwar alles mit drin (inkl. install.sh) und der kernel wird auch mit installiert, aber ich brauche den im grub ja nicht angeben. Mal sehen ob es läuft.

 

[Romep]

Hm, das hat alles zerschossen. Ich kann nichtmal mehr ein xm list machen.

Traceback (most recent call last):
  File "/usr/sbin/xm", line 5, in <module>
    from xen.xm import main
ImportError: No module named xen.xm

 

[Bauer87]

Was genau macht make install-xxxx?

Das steht doch im Makefile und lässt sich schnell nachlesen.

 

[DragonTEC]

So, drittes mal, das ich diesen Beitrag schreibe, vllt mags das Forum ja jetzt..

also, was ich eigentlich meinte ist, das du deine debian xen-pakete runterhaust (vorher natürlcih einstellungen sichern, dann aptitue purge), bis du nur noch den xen-kernel hast..

dann die kommandos von oben machen..

die ziehen dir das aktuelle testing snapshot (n vierteljahr neuer als die debian packages), compilieren das, und installieren es dann ( kopieren der xen.gz in /boot, installation sämtlicher files, tools und modules und verlinkung in upstart und /usr/bin etc.. sprich alles was sonst ne win install macht)..

dann in /boot nach der vmlinuz und xen.gz suchen und unter /etc/grub.d einen neuen grub-eintrag erstellen.. hier ist beispielsweise meiner:

menuentry '2.6.37-rc5 openSuSe Kernel mit Xen 4.0.2 unstable dom0' {
        savedefault
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        multiboot /boot/xen-4.1-unstable.gz dom0_mem=2048M iommu=1 loglvl=all guest_loglvl=all
        module /boot/vmlinuz-2.6.37-rc5-xen root=UUID=17faf325-be0d-44b3-ab4a-3f93940572bf ro root=UUID=17faf325-be0d-44b3-ab4a-3f93940572bf pciback.hide=(02:00.0)(2:00.1)(07:00.0)(07:00.1)
        module /boot/initrd.img-2.6.37-rc5-xen
}

dann neu booten und alles müsste laufen..

alternativ kannst du auch mal bunkasans install script ausprobieren (anderer threat hier im unterforum), das macht das alles (inkl. kernel kompilieren) automatisch und wenn du dein system grad eh zerschossen hast, was solls.. ansonsten ist das natürlich genau so ohne gewähr wie das, was ich hier schreib..

viel glück!

 

[Romep]

Hm habe es jetzt nochmal alles so gemacht und auch in der dom0 kompiliert. An dem Fehler hat es aber nichts geändert. Nach dem boot kann ich nichtmal xm list machen -.-

Traceback (most recent call last):
  File "/usr/sbin/xm", line 5, in <module>
    from xen.xm import main
ImportError: No module named xen.xm

Ich würde echt gerne aufgeben und das an den Nagel hängen, aber leider wäre es viel zu cool wenn da noch mein Meidacenter drauf laufen kann

edit:
Ich glaube er hier hatte das selbe Problem:

hallo nochmal,
also es hat tatsächlich geklappt. squeeze kernel und xen 4.0.2-rc-irgendwas und ich kann meine karte an eine hvm domain reichen und xbmc rennt richtig schön. bin begeistert!!
allerdings hat debian komische sachen gemacht. python 2.6 wollte das site-packages nicht finden. musste also die path variabele händisch anpassen und menche libs sind nicht unter /usr/lib wo er sie gerne hätte, sondern unter /usr/lib64. hat von euch jemand damit probleme gehabt?

gruß

Ich bin gerade am googeln.


edit2, Lösung: Die python Pfade stimmen hier irgendwie nicht. Ein "make install-tools PYTHON_PREFIX_ARG=" (hinter dem = ist schluss!) löst das ganze.

 

[Romep]

Welche Distribution benutzt ihr? Was in der dom0 läuft ist mir ja ziemlich egal.

edit: Juhu! Ich bin etwas weiter. Habe jetzt ein Ubuntu 10.04 mit selber kompiliertem Kernel und Tools! Startet und ich kann xm etc benutzen. Wahrscheinlich gibt es gleich neue Probleme

 

[Romep]

Ich kriege beim starten jetzt immer im xm dmesg:

(XEN) [VT-D]iommu.c:722: iommu_enable_translation: iommu->reg = ffff82c3fff56000
(XEN) [VT-D]iommu.c:845: iommu_fault_status: Fault Overflow
(XEN) [VT-D]iommu.c:848: iommu_fault_status: Primary Pending Fault
(XEN) [VT-D]iommu.c:823: DMAR:[DMA Write] Request device [00:02.0] fault addr ffffff000, iommu reg = ffff82c3fff56000
(XEN) DMAR:[fault reason 05h] PTE Write access is not set
(XEN) print_vtd_entries: iommu = ffff830137cf8950 bdf = 0:2.0 gmfn = ffffff
(XEN)     root_entry = ffff830137cc3000
(XEN)     root_entry[0] = 80fb001
(XEN)     context = ffff8300080fb000
(XEN)     context[10] = 1_8ac2001
(XEN)     l3 = ffff830008ac2000
(XEN)     l3_index = 3f
(XEN)     l3[3f] = 0
(XEN)     l3[3f] not present

Das hatte ich schonmal mit dem standard debian packages ... damals hatte ich keine Ahnung was ich gemacht hatte aber es war auf einmal weg. Könnte sogar ne neuinstallation gewesen sein. Jemand ne Ahnung?

edit: Keine Ahnung was ich gemacht habe, aber ein reboot und die ganzen kernel parameter rausnehmen (iommu, pciback), dann wieder ein reboot mit parameter hats scheinbar gebracht. Der Fehler ist weg. Starten kann ich die VM aber immer noch nicht Fehler in xm dmesg:

(XEN) [VT-D]iommu.c:1484: d0:PCI: unmap bdf = 0:2.0
(XEN) [VT-D]iommu.c:1362: d1:PCI: map bdf = 0:2.0
(XEN) physdev.c:61: dom1: map invalid irq 1251
(XEN) [VT-D]io.c:300: d1: bind: m_gsi=55 g_gsi=36 device=5 intx=0
(XEN) [VT-D]iommu.c:1484: d1:PCI: unmap bdf = 0:2.0
(XEN) [VT-D]iommu.c:1362: d0:PCI: map bdf = 0:2.0

IRQ 1251 kann ich mir irgendwie nicht vorstellen. Da ist noch irgendwas im argen.


edit2: Hier noch lspci -vvv vom device:

00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 12) (prog-if 00 [VGA controller])
        Subsystem: Micro-Star International Co., Ltd. Device 7636
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 1251
        Region 0: Memory at fb800000 (64-bit, non-prefetchable) [size=4M]
        Region 2: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 4: I/O ports at cc00 [size=8]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
                Address: fee0800c  Data: 4161
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a4] PCI Advanced Features
                AFCap: TP+ FLR+
                AFCtrl: FLR-
                AFStatus: TP-
        Kernel driver in use: pciback

edit3: Den Sata Controller kann ich per PCI passthrough durchreichen. Nur die Grafikkarte nicht.