Xen und 3D

[DragonTEC]

hey,

danke für den super tipp mit dem /dev/mapper! wo hast du das denn her? ^^ geht jetzt jedenfalls, wobei mir aufgefallen ist, das die performance als hda signifikant schlechter ist als als sda..

das mit der eth0 ist allerdings nicht das problem.. tritt auch auf, wenn ich dem domU eth0 sage, genau so wie, wenn ich ne ganz anderen bridgenamen nehme..

pciback.hide funktioniert leider auch nicht.. ist ihm, genau wie xen-pciback.hide, total egal.. ich versuch allerdings, die primary graka zu hiden, weil meine sec. grad in RMA ist.. geht das überhaupt?

€: Nachtrag: pciback.hide funktioniert auch nicht mit nem anderen gerät wie nem usb controler..

 

[Bunkasan]

Mit xen und lvm´s spiel ich mich schon seit ca 2 Jahren, aber erst jetzt, nachdem der GFX-Passtrough ausgereift ist, mein Haupsystem vom Dualboot umgerüstet.

Normalerweise sollte er, wenn du die /etc/network/interfaces konfiguriert hast, beim start des xend die bridge automatisch einrichten. Sieht dann in etwa so aus:

eth0      Link encap:Ethernet  Hardware Adresse xx:xx:xx:xx:xx:xx  
          inet Adresse:xxx.xxx.xxx.xxx  Bcast:192.168.xxx.255  Maske:255.255.255.0
          inet6-Adresse: xxxx::xxx:xxxx:xxxx:xxxx/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:1253 errors:0 dropped:0 overruns:0 frame:0
          TX packets:955 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:207634 (202.7 KiB)  TX bytes:213937 (208.9 KiB)

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:203 errors:0 dropped:0 overruns:0 frame:0
          TX packets:203 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:1245473 (1.1 MiB)  TX bytes:1245473 (1.1 MiB)

peth0     Link encap:Ethernet  Hardware Adresse xx:xx:xx:xx:xx:xx  
          inet6-Adresse: xxxx::xxx:xxxx:xxxx:xxxx/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metrik:1
          RX packets:7350 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6708 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:6261079 (5.9 MiB)  TX bytes:1090015 (1.0 MiB)
          Interrupt:18 

vif1.0    Link encap:Ethernet  Hardware Adresse fe:ff:ff:ff:ff:ff  
          inet6-Adresse: fe80::fcff:ffff:feff:ffff/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:2 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:32 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Hier mal meine grubconfig:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the "exec tail" line above.
menuentry "Xen 4.0 / Debian kernel Suse 2.6.34" --class ubuntu --class gnu-linux --class gnu --class os {
    insmod ext2
    set root='(hd0,msdos2)'
    search --no-floppy --fs-uuid --set d8ae04ca-4a92-4a47-810f-9927fbbef35f
    multiboot /boot/xen.gz cpufreq=xen cpuidle noreboot  loglvl=all guest_loglvl=all  vga=gfx-1280x1024x16
    module /boot/vmlinuz-2.6.34-xen dummy=dummy root=UUID=d8ae04ca-4a92-4a47-810f-9927fbbef35f intel_iommu=on ro nomodeset rootdelay=90 pciback.permissive pciback.hide=(00:1a.0)(00:1a.1)(00:1a.2)(00:1a.7)(03:00.0)(04:00.0)(04:00.1)(05:00.0)(09:00.0)(09:02.0) reassign_resources video=uvesafb:1280x1024-16,mtrr:3,ywrap,v86d
    module /boot/initrd.img-2.6.34-xen
}

Ja, es geht, allerdings darfst du sie dann erst nach dem systemstart vorm system verstecken, dazu kannst du das script verwenden:

BDFS='0000:xx:xx.x 0000:xx:xx.x'
for BDF in $BDFS
do
        [ ! -e /sys/bus/pci/devices/$BDF/driver/unbind ] || \
        echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
        echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
        echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
        ls -l /sys/bus/pci/drivers/pciback/bind | grep $BDF
        DEV=`echo $BDF | cut -b 6-12`
        DES=`lspci | grep $DEV | awk '{printf $2" "$3" "$4" "$5" "$6}'`
        if [ $? = 0 ]
            then echo "[ OK ]    "$DEV"    "$DES
            else echo "[fail]    "$DEV"    "$DES
        fi
done

EDIT: Wegen der etwas mauen Performance der LVM´s nutze ich diese auch nur für test-domU´s, Mein 7er hab ich auf nem eigenen raid.

 

[DragonTEC]

so, bin mal wieder weitergekommen.. beim pciback-hide war das problem, das das xen pciback nur als modul im kernel war.. is wohl so standard in der suse config.. das hab ich jetzt mal direkt reingebaut und schon sieht das ganze freundlicher aus..

primary vga passthrough geht zwar immernoch nicht, aber da versuch ich jetzt mal den xen testing branch anstatt dem 4.0.1er release..

was macht eigentlich das nomodeset im grub kernel-part?

€: so, testing branch erster erfolg: die network bridge haut jetzt hin.. im stable hat er mir gar keine vif, veth und tap devices angelegt, nun läufts.. primary vga passthrough SCHEINT auch zu funktionieren.. ich krieg jedenfalls keinen fehler mehr.. aber an der vga kommt auch noch nix an.. mal gucken..

 

[Bunkasan]

nomodeset deaktiviert das Kernel mode setting, hatte es mit reingenommen als ich noch mit der Konsolenauflösung gekämpft hatte.

Für VGA-Passtrough brauchst du aber, ausgenommen einige Intel-onboard Chips, defintiv den secvga.patch resp. das VBAR-PBAR mapping.

EDIT: Um auf dein Posting im Scriptthread bezug zu nehmen, in xen 4.1 unstable ist das VBAR-PBAR mapping bereits integriert.

 

[DragonTEC]

sag mal, hast du schon erfahrungen mit dem stubdom als device mapper? das qemu-dm läuft bei mir jetzt prima.. nur die gleiche vm mit stubdom-dm will nicht.. scheint zwar erst alles zu klappen, dann legt er sich aber mit einem "could not unpause domU" auf die nase..

ach ja, lustiges nebenprojekt.. ich versuch grade die LVM PV zu verschlüsseln, in der meine gäste laufen.. lustigerweise kann das luks wohl nicht, also hab ich mir jetzt mit truecrypt ne partition verschlüsselt und darin die pv erstellt.. funktioniert erstaunlich gut..

€: bääähhh.. ich werd wahnsinnig.. wenn ich ne domU von cd boote geht das (hab mal n deb installer genommen).. dann kann ich das auch installieren und alles läuft prima.. nur beim starten kann er das ding ums verrecken nciht booten "could not reed the boot device".. kann mich auch von der cd problemlos per chroot einloggen und dann prima auf dem ding arbeiten, n neuen kernel installieren, grub konfigurieren und whatever.. ich frag mich echt, warum er meine lvm lv nicht booten kann, wenn gleichzeitig das cdrom image wunderbar funktioniert.. is ne hvm und gebootet wird mit nem grub2.. disk hab ich schon als sda, ioemu:sda, hda und ioemu:hda probiert..

 

[Bunkasan]

Erfahrung ja, aber nicht die besten. PCI-Passtrough wollte nicht auf Anhieb, und ohne blieb er im blocked state stehen. hab mich dann noch nicht weiter damit beschäftigt, wobei Sicherheits- und Performanceaspekte absolut dafür sprechen würden.

Von den unverschlüsselten LV's konntest du aber booten, oder? Hatte bisher auch nur probleme bei phy-devs als sda unter Windows, aber auch noch nicht weiter damit beschäftigt. Vielleicht sollteich mal aufhören pausenlos am Script zu schrauben und auf das wesentliche konzentrieren...

 

[DragonTEC]

arg, sachen gibts..

falls irgendwer hier über google mal drauf stößt:

Falls ihr über den Deb-Installer ne HVM domU installiert habt und er, nachdem der Installer durchgelaufen ist, partou nicht von der disk booten will und immer ein "could not read the boot device" kommt, änder einfach den modus von sda oder hda auf xvda, und schon gehts..

kopf -> wand

 

[Bunkasan]

Dachte ich mir schon. Also nicht Windows spezifisch. Hatte heute ein ähnliches erlebnis mit " (vif) could not be connected. Hotplug..." bis ich auf die idee kam, mal zu schauen ob das netbk im Kernel einkompiliert ist. Crash your head to keyboard to continue...

BTW: Hatte mit dem .36 unter Ubuntu keine probleme mit xend und konsorten. Nutzt du bei deinem Deb upstart?

 

[DragonTEC]

So, everything up and running, und ich muss sagen, ich bin doch beeindruckt..

hab mal geguckt, was ich für schreibraten habe:

Dom0: ca. 3000 MB/sec Read, ca. 100 MB/sec Write
DomU: ca. 2800 MB/sec Read, ca. 60 MB/sec Write

find ich doch schon beeindruckend, vorallem wenn man bedenkt, wo die domU durchgeschliffen wird:

physische disk
-> physische partition
-> truecrypt encrypted
-> LVM PV
-> LVM VG
-> LVM LV
-> DomU disk
-> DomU partition

ach ja, und: ne, hab noch ein sysvinit laufen.. das wurde beim usb stick installer wohl einfach draufgehauen.. werd da glaub ich mal upstart nachziehen, falls es noch probleme gibt.. aber eigentlich läuft die dom0 jetzt und mehr als VMs hosten soll die ja eh nicht.. mal schauen.. is aber n guter tipp


€: vga passthrough SUXXXXX mir fliegt die vm schon um die ohren, wenn ich gfx_passthru nur aktiviere, ohne überhaupt ne grafikkarte zu übergeben.. der hvmloader bootet dann nur noch in einen qemu monitor, und das wars hab aber auch keine wirkliche fehlermeldung im log..

€2: großer schritt weiter.. ich kann nur jedem empfehlen ehtchn (XEN_EHTCHN) und gntdev (XEN_GRANT_USER) fest in den kernel zu kompilieren und nicht nur als module zu haben, oder zumindest die module dann tatsächlich auch zu laden, damit man die entsprechenden devices unter /etc/xen hat.. nun funktionieren qemu-dm und studdom-dm prima und auch mit einem gfx_passthrough fliegt mir noch nciht die vm um die ohren.. lustigerweise brauch die stubdoms ewig zum booten, wenn auch sie im aktiven system genau so schnell sind wie qemus.. konnte hier auch mit benchmarks keinen unterschied feststellen.. morgen is dann gfx-passthrough dran..

 

[DragonTEC]

kennt sich eigentlcih jemand mit dem powermanagement unter xen aus? ich wollt heut mal n bissel an meinem cool'n'quiet rumspielen, musste aber feststellen, dass das im kernel gar nicht aktiv ist, sondern xen da die kontrolle übernommen hat.. dies funktioniert für MHz auch prima, nur vcore scheint überhaupt nicht betroffen zu sein ist aber n zentrales mittel um strom zu sparen..

€: hmm.. vga passthrough klappt irgendwie immernoch nicht.. ich hab jetzt auch mal emin bios in den /tools/firmware/vgabios ordner gepackt, aber irgendwie interessiert ihn das nicht.. er hängt sich immernoch beim starten des vga bios auf, krepiert da und fliegt dann mit einem device model is not ready oder so späßen.. was macht denn dein script da genau bunkasan?

 

[Bunkasan]

Das Bios einkompilieren musst du (oder zumindest ich) nur bei der 4.0x, bei der 4.1 war es nicht mehr nötig. Im Script wird das Bios in "vgabios-pt.bin" umbenannt und nach "/tools/firmware/vgabios/" kopiert. Danach ist ein rekompile notwendig. Versuchst du eigentlich noch den primary passthrough oder ist deine zweitkarte aus der RMA zurück? Beim primary musst du die Karte ja direkt vorm start der VM hiden, da dabei das Bild der dom0 flöten geht. Was zumindest bei mir mit dem .36 beim letzten versuch nicht mehr möglich war. Gab scheinbar ne änderung in der "/sys/bus/drivers/pciback/*" struktur. Habe ich aber noch nich weiter verfolgt.

 

[DragonTEC]

jap, versuch immernoch primary.. RMA halt.. aber das hiden der primary geht ohne probleme.. hatte am anfang n paar probs weil die xen bridge sich am anfang nicht connecten kann und ohne monitor is selbst ein dhclient eintippen schwierig.. aber mit static IP adressen klappts jetzt, die graka is gehided und eigentlich läuft alles.. nur fliegt mir halt mein device model immer um die ohren..

 

[Bunkasan]

Hast du eigentlich schon (erfolgreich) versucht andere hardware in die vm einzubinden?

 

[Jared566]

Hallo,

Wäre schön wenn ihr dazu eine Anleitung verfassen könntet, mich interessiert das Thema nämlich auch

Entweder hier im Forum, ansonsten könnte ich euch auch Webspace oder ein Wiki zur verfügung stellen

Was muss denn jetzt alles installiert werden damit ich unter Ubuntu 10.04 xen mit vga-passthrou zum laufen bekomme? Von mir aus auch unter Debian ^^

Mfg Jared

 

[DragonTEC]

Ja, ne Anleitung werd ich definitiv schreiben, sobald das ganze mal stabil läuft und ich auch was zum anleiten habe..

Generell brauchst du eigentlich nur nen neuen kernel und ne xen version.. die kann dir sogar das bunkasan-script installieren, siehe anderer threat im gleichen forum..

Allerdings eine Warhnung vorweg: das is noch sehr experimentel, also bitte nicht auf nem system testen, das du grade produktiv nutzt

ansonsten brauchst du softwarmäßig eigentlich nicht viel mehr.. interessanter wirds bei der hardware.. wenn die nämlich das ganze nicht unterstützt, wirds schwierig.. ich hab zwar gelesen, das genze funktioniert auch ohne iommu hardware mit ner paravirtualisierten VM anstatt ner richtigen VM, aber dafür mag ich meine hand nicht ins feuer legen.. was hast du denn bei dir unterm schreibtisch stehen?

€: @ Bunkasan: ja, andere hardware geht ohne probleme.. nur wenn gfx_passthru enabled ist, krieg ich anstatt meiner VM nur immer den doofen qemu monitor

 

[Jared566]

noch habe ich einen q6600 + hd4850 auf einem ASUS P5WD2-E Premium. Dazu habe ich noch eine 7300SE rumliegen, die ich ja für die 1. Maschine nutzen kann und die 4580 dann durchschleifen lasse.

Wenn es denn mit meiner Hardware laufen sollte ^^

 

[Bunkasan]

@ Jared: Da dein Board mit dem 975X Chipsatz kein VT-d unterstüzt, bleibt dir nur die Paravirtualisierung. Dort laufen dir allerdings nur Linuxkernels, da der nicht quelloffene Windowskernel nicht angepasst oder ausgetauscht werden kann. PCI Passtrough ist bei PV-Gästen relativ einfach, aber ob VGA möglich ist, kann ich dir auf Anhieb nicht sagen.

@ Dragontec: Das mit dem Qemu Monitor ist normal. Sobald du den gfx-passthrough aktivierst hast du nur noch auf der entsprechenden Hardware Bildausgabe. Zumindest theoretisch. Komischerweise bootet er bei mir das Windows bei deaktiviertem gfx-passtrough erst im VNC-Fenster um dann den Anmeldebildschirm und Windows selbst auf der eingebundenen Grafikkarte auszugeben. Im VNC bleibt der Bootscreen stehen.

 

[DragonTEC]

das das normal is freut mich ja theoretisch.. praktisch läd der aber ums verrecken das domU bios nich.. xm dmesg sieht so aus:

(XEN) domctl.c:981:d0 memory_map:add: gfn=e0000 mfn=d0000 nr_mfns=10000
(XEN) HVM2: pci dev 03:0 bar 14 size 01000000: f0000008
(XEN) domctl.c:981:d0 memory_map:add: gfn=f1000 mfn=fe9e0 nr_mfns=20
(XEN) HVM2: pci dev 05:0 bar 18 size 00020000: f1000004
(XEN) HVM2: pci dev 05:0 bar 30 size 00020000: f1020000
(XEN) HVM2: pci dev 03:0 bar 10 size 00000100: 0000c001
(XEN) HVM2: pci dev 04:0 bar 10 size 00000100: 0000c101
(XEN) HVM2: pci dev 04:0 bar 14 size 00000100: f1040000
(XEN) HVM2: pci dev 05:0 bar 20 size 00000100: 0000c201
(XEN) domctl.c:1037:d0 ioport_map:add f_gport=c200 f_mport=e000 np=100
(XEN) HVM2: pci dev 01:2 bar 20 size 00000020: 0000c301
(XEN) HVM2: pci dev 01:1 bar 20 size 00000010: 0000c321
(XEN) HVM2: Multiprocessor initialisation:
(XEN) HVM2:  - CPU0 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done.
(XEN) HVM2:  - CPU1 ... 48-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done.
(XEN) HVM2: Testing HVM environment:
(XEN) HVM2:  - REP INSB across page boundaries ... passed
(XEN) HVM2:  - GS base MSRs and SWAPGS ... passed
(XEN) HVM2: Passed 2 of 2 tests
(XEN) HVM2: Writing SMBIOS tables ...
(XEN) HVM2: Loading ROMBIOS ...
(XEN) HVM2: 9660 bytes of ROMBIOS high-memory extensions:
(XEN) HVM2:   Relocating to 0xfc000000-0xfc0025bc ... done
(XEN) HVM2: Creating MP tables ...
(XEN) HVM2: Loading VGABIOS of passthroughed gfx ...
(XEN) HVM2: Loading PCI Option ROM ...
(XEN) HVM2:  - Manufacturer: http://etherboot.org
(XEN) HVM2:  - Product name: gPXE
(XEN) HVM2: Loading ACPI ...
(XEN) HVM2:  - Lo data: 000ea020-000ea04f
(XEN) HVM2:  - Hi data: fc002800-fc01291f
(XEN) HVM2: vm86 TSS at fc012c00
(XEN) HVM2: BIOS map:
(XEN) HVM2:  c0000-cefff: VGA BIOS
(XEN) HVM2:  cf000-dcfff: Etherboot ROM
(XEN) HVM2:  eb000-eb17b: SMBIOS tables
(XEN) HVM2:  f0000-fffff: Main BIOS
(XEN) HVM2: E820 table:
(XEN) HVM2:  [00]: 00000000 - 0009e000: RAM
(XEN) HVM2:  [01]: 0009e000 - 0009fc00: RESERVED
(XEN) HVM2:  [02]: 0009fc00 - 000a0000: RESERVED
(XEN) HVM2:  HOLE: 000a0000 - 000e0000
(XEN) HVM2:  [03]: 000e0000 - 00100000: RESERVED
(XEN) HVM2:  [04]: 00100000 - 40000000: RAM
(XEN) HVM2:  HOLE: 40000000 - fc000000
(XEN) HVM2:  [05]: fc000000 - 00000000: RESERVED
(XEN) HVM2: Invoking ROMBIOS ...
(XEN) HVM2: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $

qemu-log:

domid: 2
config qemu network with xen bridge for  tap2.0 xen0
Using xvda for guest's hda
Using file /dev/mapper/XEN_VMs-domU in read-write mode
Watching /local/domain/0/device-model/2/logdirty/cmd
Watching /local/domain/0/device-model/2/command
Watching /local/domain/2/cpu
qemu_map_cache_init nr_buckets = 10000 size 4194304
shared page at pfn feffd
buffered io page at pfn feffb
Guest uuid = b0b9d002-4184-1628-0202-449ab7bb4cff
Time offset set 0
pcilib: Cannot open /sys/bus/pci/devices/0000:00:1f.0/config
pcilib: Cannot open /sys/bus/pci/devices/0000:00:1f.0/config
pcilib: Cannot open /sys/bus/pci/devices/0000:00:1f.0/config
Register xen platform.
Done register platform.
platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state.
xs_read(/local/domain/0/device-model/2/xen_extended_power_mgmt): read error
Log-dirty: no command yet.
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0
vcpu-set: watch node error.
xs_read(/local/domain/2/log-throttling): read error
qemu: ignoring not-understood drive `/local/domain/2/log-throttling'
medium change watch on `/local/domain/2/log-throttling' - unknown device, ignored
dm-command: hot insert pass-through pci dev
register_real_device: Assigning real physical device 06:00.0 ...
register_real_device: Enable MSI translation via per device option
register_real_device: Disable power management
pt_iomul_init: Error: pt_iomul_init: No such device: setup io multiplexing failed! 0x6:0x0.0x0
pt_register_regions: IO region registered (size=0x10000000 base_addr=0xd000000c)
pt_register_regions: IO region registered (size=0x00020000 base_addr=0xfe9e0004)
pt_register_regions: IO region registered (size=0x00000100 base_addr=0x0000e001)
pt_register_regions: Expansion ROM registered (size=0x00020000 base_addr=0xfe9c0002)
pt_msi_setup: msi mapped with pirq 57
pci_intx: intx=1
register_real_device: Real physical device 06:00.0 registered successfuly!
IRQ type = MSI-INTx
char device redirected to /dev/pts/2
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
xen be: console-0: xen be: console-0: initialise() failed
initialise() failed
pt_iomem_map: e_phys=e0000000 maddr=d0000000 type=8 len=268435456 index=0 first_map=1
pt_iomem_map: e_phys=f1000000 maddr=fe9e0000 type=0 len=131072 index=2 first_map=1
pt_ioport_map: e_phys=c200 pio_base=e000 len=256 index=4 first_map=1

das qemu log is außer ein paar consolenfehlern unauffällig und woanders find ich auch nix.. die domU läuft dann zwar, is aber nicht im Running-state und n output krieg ich auch nicht..

€: hab mal as qemu log noch reingepackt..

€2: bunkasan, wie hast du eigentlich dein graka bios exportiert? bei mir wollte gpu-z nicht und ich hab mir n bios aus der internet vga bios db gezogen.. vllt is das ja das problem?

 

[Bunkasan]

Jap, er bleibt bei dir defintitiv beim laden des VGA BIOS stehen.

...
(XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
(XEN) stdvga.c:147:d1 entering stdvga and caching modes
...

Ich nehm auch ein nichtmal Vendor eigenes Asus BIOS für ne Sapphire Karte, das sollte das Problem nicht sein...

Da fällt mir noch was ein, ist das die ATI die du versuchst durchzureichen? Falls ja, musst du unbedingt auch den zugehörigen HDMI-Audiocontroller mit durchreichen.
Beides als ein Device mit 2 Funktionen zB: "04:00.0,1"

EDIT: Vollgas zurück... habe gerade festellen müssen, dass er bei mir an genau der selben stelle stehen bleibt, wenn ich bei der 4.1 gfx-passtrough aktiviere...

 

[DragonTEC]

ja, is die ati, aber ich hab immer beide versucht mit durchzureichen.. als ich das log gezogen hab wars das erste mal ohne..