Werde ich mit einer vega rx 64 weniger probleme haben sie mit passthrough durchzureichen?
Matrox g550 aktivieren nvidia passthrough kvm
(Themenstarter)
Anmeldungsdatum: Beiträge: 205 Wohnort: St.Gallen |
|
||||||
Anmeldungsdatum: Beiträge: 12990 Wohnort: Oldenburg/Erlangen |
Der Rest sind nur Positions- und Identifizierungsangaben: Mit welcher Bezeichnung soll in anderen Parametern auf das Ding verwiesen werden, an welches virtuelles Bussystem soll es angeschlossen werden und welche virtuelle PCI Adresse soll es in diesem Bussystem verwenden.
Da ist von auszugehen. Auf alle Fälle brauchst du damit keine Features beschneiden um den Herstellertreiber überhaupt zum laufen zu kriegen, der setzt sich nicht einfach beleidigt in eine Ecke wenn er merkt dass er in einem Käfig läuft. Da könntest du wahrscheinlich auch gleich dein Glück mit TianoCore anstelle von SeaBIOS versuchen - das macht viel weniger Probleme, gerade auch im Bezug auf den Host. Allerdings kann Windows erst seit Win8 einen reinen UEFI Boot vollziehen, mit Win7 und älter bringt das nichts, der benötigt trotz UEFI Unterstützung immer noch die alte VESA BIOS Extension für die Grafikkarte. |
||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 205 Wohnort: St.Gallen |
Ich bin der Anleitung gefolgt stimmt MAX_CONCURRENT_THREAD_NUMBER = 8 ? Ich besitze einen AMD FX(tm)-8350 Eight-Core Processor. Muss ich den wenn TinaoCore läuft das Bios umstellen auf UEFI ? Was genau ist Locate the TARGET_ARCH ? wenn ich beide möchte ist es den X64, IA32 ?
|
||||||
Anmeldungsdatum: Beiträge: 12990 Wohnort: Oldenburg/Erlangen |
Befindet sich fertig im Paket |
||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 205 Wohnort: St.Gallen |
Habe ich installiert. Sollte ich in diesem Fall beim Host BIOS mit UEFI starten? Ich arbeite jetzt mit Ubuntu 17.10 mit der Überlegung das die Unterstützung früh die GPU besser ist? Ich konnte Ubuntu 17.10 auf dem Gast installieren aber nicht mehr starten. Wenn ich den Start von KVM beende fährt mir das Gastsystem nicht sauber herunter so dass ich den Host ausschalten muss ein Reboot langt nicht um KVM wider zu starten. Eigenlicht ist es bis auf /etc/modprobe.d/blacklist-gpu.conf das gleiche System sollte ich da GPU-PRO eintragen? Leider habe ich noch ein paar Fehlermeldungen.
Meine /usr/vm1 Ist -M q35 korrekt?
Wie behebe ich das mit der fehlenden firmware?
|
||||||
Anmeldungsdatum: Beiträge: 12990 Wohnort: Oldenburg/Erlangen |
Wenn das BIOS von allen Grafikkarten GOP unterstützt, wäre es auf alle Fälle besser wenn der Host auch mit UEFI startet - ansonsten bringt es aber keine Vorteile.
Wie meinen?
Dazu fällt mir gerade noch etwas ein: Seit einiger Zeit kannst du die Hardware auch direkt Damit würde bei dir der ganze Kram mit der Konfigurationsdatei einfach wegfallen, du müsstest nur noch Qemu starten.
Die vorhergehenden Warnungen sind recht selbsterklärend, zu der Fehlermeldung selbst kann ich nicht viel sagen - ich reiche stattdessen gleich einen kompletten USB Controller durch. Bei den älteren Boards war es ja noch üblich haufenweise separate USB 2.0 Controller im Chipsatz zu haben (die bei meinem Board auch noch eine sehr günstige IOMMU Gruppenzuweisung hatten), inzwischen läuft das leider vermehrt über zentrale vereinzelte USB 3.x Controller... Der Fehlerwert weist aber darauf hin, dass die Gerätedatei die er da versucht zu öffnen gar nicht existiert. Das wirkt schon etwas suspekt, eine kurze Suche danach zeigte eine recht wichtige und Zentrale Funktion dafür auf.
Üblicherweise wird der i440fx Chipsatz empfohlen und standardmäßig verwendet, der ist ziemlich einfach aufgebaut und hat den Ruf am besten unterstützt zu werden - außerdem ist die Konfiguration etwas einfacher, weil er nur PCI und IDE unterstützt und kein PCIe oder SATA. Das spielt in der VM aber keine Rolle, so wird trotzdem empfohlen dieses alte Relikt zu benutzen anstelle des moderneren q35 Chipsatz. Beim q35 müsstest du erst einmal einen PCIe root port und eine PCI Brücke definieren, sofern das Qemu nicht auf magische Art und Weise selbst hinbekommt...
Wie unschwer an den Dateinamen zu erkennen ist betrifft das nur die vor kurzem erst veröffentlichten Raven Ridge APUs, das braucht dich nicht zu interessieren. Das wird irgendwann mit einem Update vom Firmware Paket von alleine verschwinden. |
||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 205 Wohnort: St.Gallen |
Hallo Irgend wann kriege ich es glaube vielleicht hin. Bin jetzt auf Ubuntu 18.04 und es gefällt mir. Ich bin soweit durch mit dieser Anleitung. https://ycnrg.org/vga-passthrough-with-ovmf-vfio/ Ich denke mein Problem ist das beide Grafikarten in Verwendung sind was zum einfrieren meines PC führt wenn ich die VM starte. Kann ich die vega 64 irgendwo eintragen damit sie nicht gestartet wird? und wenn wie? Leztes mal habe ich
Geändet aber das geht jetzt nicht sind ja beide AMD oder ist meine Überlegung falsch? |
||||||
Anmeldungsdatum: Beiträge: 12990 Wohnort: Oldenburg/Erlangen |
Du brauchst die Karte nicht blacklisten, du musst einfach dafür sorgen dass das gewünschte Modul vor dem Treiber geladen wird. Der Treiber weist sich nicht selbst zu, sondern der Kernel sucht einfach nach einem passenden Modul für Hardware die noch keins zugewiesen hat. Die modprobe Konfigurationsdateien erlauben dir auch, eine zusätzliche Abhängigkeit zu definieren, sodass du zB dafür sorgen kannst, dass das vfio-pci Modul immer als Abhängigkeit vom radeon Treiber direkt vor diesem geladen wird. Ich komme erst Mittwoch wieder an meinen VM Rechner um zu schauen wie ich das genau gemacht habe, aber es sollte dann ungefähr so aussehen (PCI IDs ggf anpassen!): softdep drm pre: vfio-pci options vfio-pci ids=1002:687f,1002:aad8 Damit läd er direkt vor den freien Grafiktreibern das vfio-pci Modul, welches sich direkt die Hardware mit den angegebenen IDs krallt und daher den Grafiktreiber aussperrt. Die Hardware kann jetzt direkt von Qemu genutzt werden, irgendwelche Skripte zum laden oder entladen von Modulen sind nicht mehr nötig. Einzig die Geschichte mit der VESA BIOS Extension kann hier noch Ärger machen, falls bei dir noch nicht alles über UEFI und GOP läuft - allerdings meiner Erfahrung nach erst, wenn man auf dem Host versucht in ein virtuelles Terminal zu wechseln. |
||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 205 Wohnort: St.Gallen |
Ich habe so weit ich es verstanden habe geändert. Hat aber leider keine Verbesserung gebracht.
UEFI ist in Gebrauch.
Freue mich auf Mittwoch wen du zeit hast mir zu erklären wie es du zum laufen gebracht hast. |
||||||
Anmeldungsdatum: Beiträge: 12990 Wohnort: Oldenburg/Erlangen |
Das muss in die Konfigurationsdateien von modprobe, also /etc/modprobe.d/ - in der Konfigurationsdatei von Initramfs kannst du nur angeben welche Module da reingestopft und in der Frühphase des Bootens geladen werden. In der Datei solltest du gar nichts machen müssen, sollte das System den Treiber ins Initramfs stopfen musst du dieses nur neu generieren, durch die neue Abhängigkeit vom Treiber wird es dann wenn nötig automatisch da reingestopft.
Die interessantere Frage wäre allerdings die nach GOP, wenn GOP nicht benutzt wird hat man vom UEFI keinen Vorteil. Wie man das genau überprüft weiß ich nicht, aber vermutlich kann man es daran erkennen, ob das vesafb Modul geladen wurde oder nicht - ich glaube das liegt in Ubuntu noch als separates Modul vor. |
||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 205 Wohnort: St.Gallen |
Ich finde nichts in /etc/modprobe.d/ was mit modprobe. sudo ls /etc/modprobe.d/ alsa-base.conf blacklist-framebuffer.conf iwlwifi.conf blacklist-ath_pci.conf blacklist-modem.conf qemu-system-x86.conf blacklist.conf blacklist-oss.conf blacklist-firewire.conf blacklist-rare-network.conf Danke für deine Hilfe es tut mir leid das meine Kenntnisse von Ubuntu nicht so gut sind damit ich deine antworten richtig umsetzen kann. |
||||||
Anmeldungsdatum: Beiträge: 12990 Wohnort: Oldenburg/Erlangen |
Es geht um das Verzeichnis. Leg dir ne Datei an - Name ist Wumpe, muss nur auf .conf enden. Siehe Manpage zu Es gibt Manpages zu so gut wie allem, sogar zu einzelnen Konfigurationsdateien - die helfen dir weiter. Einige sind sogar auf Deutsch verfügbar. |
||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 205 Wohnort: St.Gallen |
Die VM startet ohne das der Host einfriert. Leider kommt er nicht über das booten hinaus. Bis jetzt kommt die anzeige TianoCore mit der Info Start Boot Option und das war es dann auch schon. |
||||||
Anmeldungsdatum: Beiträge: 12990 Wohnort: Oldenburg/Erlangen |
Dann passt eventuell mit der TianoCore Version etwas nicht. Das Projekt hat keine offiziellen Releases, daher nimmt jeder Distributor einfach immer die jeweils aktuelle Revision - und da es damit eben auch keine Ankündigungen von neuen Releases gibt die dem Distributor einen Anlass für ein Update liefern, wird das Teil leider in der Regel auch nur selten aktualisiert... Ich weiß nicht wie alt die Version in den Quellen ist, aber jetzt wo du es sagst erinnere ich mich noch daran, dass es vor ein paar Kernel Versionen (oder wars ein Qemu Update?) irgend eine Änderung gab, die wohl mit der TianoCore Kompatibilität gebrochen hat und dementsprechend eine hinreichend aktuelle Version benötigt wird. Dummerweise ist es nicht einfach das Ding selbst durch den Compiler zu schieben, da bin ich froh dass dies bei Arch über das AUR halbwegs automatisiert ist... Eventuell findest du eine aktuellere Bezugsquelle, ansonsten musst du in den sauren Apfel beißen und es selbst probieren. |
||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 205 Wohnort: St.Gallen |
Ich denke da hast du recht. obwohl auf https://github.com/tianocore/tianocore.github.io/wiki/Common-instructions ist es nicht schlecht beschrieben. Meine Conf/target.txt sieht folgenderweise aus: # # # ALL Paths are Relative to WORKSPACE # Separate multiple LIST entries with a SINGLE SPACE character, do not use comma characters. # Un-set an option by either commenting out the line, or not setting a value. # # PROPERTY Type Use Description # ---------------- -------- -------- ----------------------------------------------------------- # ACTIVE_PLATFORM Filename Recommended Specify the WORKSPACE relative Path and Filename # of the platform description file that will be used for the # build. This line is required if and only if the current # working directory does not contain one or more description # files. ACTIVE_PLATFORM = MdeModulePkg/MdeModulePkg.dsc # TARGET List Optional Zero or more of the following: DEBUG, RELEASE, NOOPT # UserDefined; separated by a space character. # If the line is missing or no value is specified, all # valid targets specified in the platform description file # will attempt to be built. The following line will build # DEBUG platform target. TARGET = DEBUG # TARGET_ARCH List Optional What kind of architecture is the binary being target for. # One, or more, of the following, IA32, IPF, X64, EBC, ARM # or AArch64. # Multiple values can be specified on a single line, using # space charaters to separate the values. These are used # during the parsing of a platform description file, # restricting the build output target(s.) # The Build Target ARCH is determined by (precedence high to low): # Command-line: -a ARCH option # target.txt: TARGET_ARCH values # DSC file: [Defines] SUPPORTED_ARCHITECTURES tag # If not specified, then all valid architectures specified # in the platform file, for which tools are available, will be # built. TARGET_ARCH = X64 # TOOL_DEFINITION_FILE Filename Optional Specify the name of the filename to use for specifying # the tools to use for the build. If not specified, # WORKSPACE/Conf/tools_def.txt will be used for the build. TOOL_CHAIN_CONF = Conf/tools_def.txt # TAGNAME List Optional Specify the name(s) of the tools_def.txt TagName to use. # MAX_CONCURRENT_THREAD_NUMBER NUMBER Optional The number of concurrent threads. If not specified or set # to zero, tool automatically detect number of processor # threads. Recommend to set this value to one less than the # number of your computer cores or CPUs. When value set to 1, # means disable multi-thread build, value set to more than 1, # means user specify the thread number to build. Not specify # the default value in this file. # MAX_CONCURRENT_THREAD_NUMBER = 1 # BUILD_RULE_CONF Filename Optional Specify the file name to use for the build rules that are followed # when generating Makefiles. If not specified, the file: # WORKSPACE/Conf/build_rule.txt will be used BUILD_RULE_CONF = Conf/build_rule.txt Leider bekomme ich folgende Fehlermeldung
Sollte ich es mit eine andren Compiler zu versuchen? Oder habe ich die falsche ACTIVE_PLATFORM gewählt? Ich habe https://github.com/OP-TEE/optee_os/issues/832 und https://github.com/OP-TEE/optee_os/issues/842 gelesen bin aber nicht schlauer geworden. |