[Erfahrungsbericht] Virtualisierung mit PCI-Passthrough auf Manjaro Linux

Arjab schrieb:
Wenn du von der GPU im zweiten Slot dein Host-System booten kannst, scheint der Teil ja zu funktionieren, oder?
Ich kann nur dann über die GPU im zweiten Slot booten, wenn CSM deaktiviert ist, doch dann bekomme ich weder auf meinem zweiten Monitor, noch durch Spice ein Bild.
Arjab schrieb:
Wenn du die VM mit Spice startest, wird dann im System (Windows?) die Grafikkarte überhaupt erkannt?
Erst durch Aktivierung von CSM bekomme ich in Spice überhaupt ein Bild, kann Windows installieren, dort meine Vega unter den Geräten finden, allerdings nach einem Neustart der VM nicht mehr in Windows booten.
Der Fehlercode 43 scheint noch nicht vorgekommen zu sein (sofern ich alles richtig gecheckt/erkannt habe).
Die Vega sollte auf jeden Fall richtig an vfio übergeben sein, gibt mir aber wie gesagt kein Bild auf dem zweiten Monitor aus:
Ich bedanke mich auf jeden Fall für deine Mühe!
 
  • Gefällt mir
Reaktionen: Arjab
Hi,
ich hab mir seit Svens Notiz schon vorgenommen, hier mal rein zu schauen und auch von meiner Erfahrung zu berichten. Ich wollte so ein Thread selber mal starten, da meine Erwähnungen hier im Forum von meiner Gaming-VM doch immer ein gewisses Interesse hervorgerufen haben. Ich habe nun seit knapp einem Jahr ein virtualisiertes Windows auf einem Ryzen 1700X, X370 Taichi, passive RX460 (Gast) und Vega 64 unter Arch Linux. Alles in einem WaKü Custom Loop. Ende des Jahres wird dann hoffentlich auf Zen3 und einer neuen Grafikkarte aufgerüstet. :)

Die VM läuft wunderbar. Die Spiele-Performance ist auf einem Level mit einem nativen Windows. Bei schlechtem oder gar kein CPU Pinning waren die Frametimes je nach Spiel, jedoch nicht so gut. Doch mit ein bisschen probieren, lesen und testen hab ich auch das in den Griff bekommen. Achja, und beim starten der VM werden die Kerne exklusiv an die VM übergeben. Dies lässt sich z.B. mit cset (Infos z.B. hier oder hier) realisieren. Macht man das nicht, nutzt Linux weiterhin alle Kerne, was zu größeren Latenzen in der VM führen kann, insbesondere wenn der Host nicht nur idelt. Und das tut der Host bei mir nie, daher auch kein Dual-Boot.

Zur Bildausgabe habe ich Looking Glass getestet, war mit der Performance bei 1440p@144Hz aber nicht begeistert. Außerdem funktioniert Freesync so nicht. Daher wechsel ich jetzt einfach den Eingang am Monitor, wenn ich die VM starte. Maus und Tastatur reiche ich via USB-Passthrough durch und share sie dann über Barrier mit meinem Host. Ich könnte das USB-Passthrough auch weg lassen und via Barrier Maus und Tastatur einfach an die VM sharen, doch handelt man sich damit ein wenig Latenz ein. Für Office kein Problem, bei Spielen evt schon.
Für Audio hab ich einfach einen USB-Controller meines Mainboards via PCI-Passthrough an die VM übergeben. An einem der Ports hängt eine USB-Soundkarte/Kopfhörerverstärker. Da ich das Windows nur für Spiele nutze, und dabei immer entweder meine Kopfhörer verwende oder wenn ich am TV spiele Sound über HDMI bekomme, habe ich mich mit Audio-Passthrough gar nicht mehr beschäftigt.

In der Zukunft will ich noch probieren, meine Gast-Grafik auch im Host für grafiklastige Anwendungen zu benutzen. Via GPU offloading ist das theoretisch möglich. Mal schauen, ob mir dann der AMD Resetbug dabei einen Strich durch die Rechnung macht.

Das war ein kleiner Einblick in meine Konfiguration und Erfahrung. Falls wer Fragen oder Anregungen hat, raus damit. Ich gehe gerne weiter ins Detail. Auch an Diskussionen über verschiedene Lösungen bin ich interessiert, sofern @Arjab nichts dagengen hat. :)


__________

Zum Reset Bug: Ist das noch immer ein Problem? Ich dachte eigentlich, das würde in Verbindung mit libvirt nur noch bei harten Shutdowns Probleme machen, also z.B. wenn die VM abstürzt. Ich kann meine VM munter neustarten, herunterfahren und wieder starten. Oder nutzt ihr die Gast-Grafikkarte auch unter Linux? Ich habe recht häufig gelesen, dass das Probleme machen kann. Das habe ich damit umgangen, dass mein Kernel für die Grafikkarte nur den vfio-pci-Treiber laden darf.

@Mapman Welchen Treiber lädst du für die Gast-GPU unter Linux? Lässt sich mit "lspci -vv" herausfinden. Was ist der genaue Fehler, wenn du die VM versuchst zu booten? Startet die VM? Zeigt libvirt cpu usage an? Falls das Bild einfach schwarz ist, die CPU allerdings genutzt wird (schwakende Auslastung in libvirt): Das Problem hatte ich auch, wenn der AMD-Treiber noch nicht installiert war. Das Bild war schwarz, Windows allerdings gebootet. Nach etwa 10-15 Minuten kam das Bild dann aber. Ich vermute, das WIndows hat im Hintergrund einen Treiber installiert. Dann hab ich den AMD-Treiber installiert und von da an hatte ich nie wieder Probleme.
Übrigens, wenn deine beiden Grafikkarten in den ersten zwei Slots deines Mainboards sind, ist es von der Performance eigentlich egal, welche Grafikkarte wo steckt. Beide Grafikkarten sollten dann mit 8 PCIe-Lanes laufen. Somit kann die Host-GPU auch in Slot 1. Ich selber wollte das nicht, daher ist bei mir in Slot 1 die Vega und die Host-GPU in Slot 4. Somit läuft die Vega mit vollen 16 Lanes und die Host-GPU lediglich über den Chipsatz mit 4 PCIe-v2-Lanes, wenn ich mich richtig erinnere. Für die kleine GPU aber völlig in Ordnung. :)
 
@WilliTheSmith Kurzer Anmerkung zu Slot 1 PCI-Express, theoretisch sollte es keine Rolle spielen, praktisch bin ich verzweifelt bei mir genau das zu verwirklichen. Manchmal ist der erste Slot einfach irgendwie reserviert für die Host Grafik, hatte nur Probleme und als ich dann in den nächsten Slot gewechselt hatte und die Host GPU im Slot 1 lief war alles super, passiert in Abhängigkeit der eingesetzten Hardware.

Nachteil dieser Aktion war allerdings, dass meine 3-Slot Grafikkarte ich so umgebaut habe, dass ich weniger PCI-X Slots zur Verfügung habe die ich für Erweiterungen nutzen kann wie Storage Controller und Netzwerkkarte, was davor einen PCIX Slot mehr realisierbar durch die Motherboard Gegebenheiten und die tripple Slot Grafikkarte einiges abgedeckt hatte und die Dual Slot Host GPU zusätzlich. und wenn ich mich recht entsinne nur ein PCI-X verfügbar war. Bei 6 Onboard PCI-X x16 Slots (Baulänge) und 2 vollwertige x 16PCIX Lanes, 2x8PCIX Lanes und 2x 4PCIX Lanes

@CPU-Pinning ja das sollte auch erwähnt werden macht es "smoother" das Spiele Erlebnis.

Andere Frage an die Virtual Gaming Machine Owner:
Macht Ihr Euch einen Kopf wegen VM und evtl. Sanktionen? Seitens der Spiele- Publisher und -Industrie?

Habe mich da nur bisschen belesen und ist eher "gedulded" bzw. stellenweise auch sanktioniert.
z.B. traue ich mich aktuell nicht Valorant zu starten auf der VM.

Ich habe die Physikalische Festplatte der VM durchgereicht und kann beide Welten leben...
 
Zuletzt bearbeitet:
@WilliTheSmith Wenn ich es über Spice versuche, habe ich ja schon erzählt, dass ich normal Windows installieren kann und auch danach Änderungen vornehmen kann. Wenn ich die VM nun allerdings herunterfahre und wieder starten möchte, versucht Windows zu booten, hängt sich aber quasi auf. Die Ladepunkte während dem Starten verharren dann nämlich einfach in einer Position und auch nach längerem Warten tut sich nichts mehr. Die CPU Last bleibt aber in geringen Maßen erhalten. "lspci -vv" gibt mir stets aus, dass die Vega die vfio Treiber lädt.
Ohne Spice habe ich eben einfach nur einen Blackscreen auf dem zweiten Monitor, doch Last lässt sich auch hier ähnlich zum Spice Vorgehen bei meinem 1600er erkennen.
Um zum Slotwechsel zu kommen: Ich habe bereits versucht, die Vega in Slot 2 und demnach die GT 710 in Slot 1 zu nutzen. Allerdings (unter nativem Windows 10 getestet) ist die Performance im 2. Slot nicht allzu gut. Meine Vermutung ist, dass die Ursache an einem PCI-E 2.0 Slot als 2. Slot liegt, kann mich aber natürlich auch irren. Würde mich freuen, wenn ihr mir vielleicht noch etwas helfen könnt, aber schon mal ein großes Danke für die Hilfe und den damit verbundenen Aufwand.
Allerdings überlege ich derzeit das Thema zwar weiterhin zu verfolgen und Neues auszuprobieren, doch erst gegen Ende des Jahre mich vollkommen dahinter zu setzen. Bis dahin werde ich nämlich auf jeden Fall auf Zen 2 bzw. schon Zen 3 upgraden, samt neuem Mainboard und evtl. neuer GPU.
 
Big Ed schrieb:
@WilliTheSmith Kurzer Anmerkung zu Slot 1 PCI-Express, theoretisch sollte es keine Rolle spielen, praktisch bin ich verzweifelt bei mir genau das zu verwirklichen.
Ja, manche Mainboards sind da echt blöd. Hab ich auch schon gehört. Manche machen ihren POST immer auf der ersten GPU, was dann beim Passtrough dieser Probleme machen kann. Deshalb wird mein nächstes Mainboard auch hauptsächlich nach Kriterien ausgesucht, die mir perfektes VFIO bescheren. Vor allem würde ich gerne eine NVMe und den SATA Controller durchreichen. :)

Was ich aber eigentlich damit sagen wollte: Wenn es mit Gast-GPU in Slot 1 und Host in Slot 2 nicht funktioniert, einfach mal tauschen. Das sollte keinen Unterschied in der Performance machen (beide GPUs haben so auf den Meisten Boards 8 Lanes), andere Probleme aber evt. lösen.

Big Ed schrieb:
Andere Frage an die Virtual Gaming Machine Owner:
Macht Ihr Euch einen Kopf wegen VM und evtl. Sanktionen? Seitens der Spiele- Publisher und -Industrie?

Habe mich da nur bisschen belesen und ist eher "gedulded" bzw. stellenweise auch sanktioniert.
z.B. traue ich mich aktuell nicht Valorant zu starten auf der VM.
Ich hab da auch einiges gelesen. Ich mache mir da aber eigentlich keinen Kopf drum. Wahrscheinlich ist man mit CPU host-passthrough eh schon recht safe. Theoretisch kann man noch das Hypervisor- und KVM-Flag verstecken, was dann eine Erkennung wohl äußerst schwierig macht, allerdings die Performance negativ beeinflussen kann? Da kann ich nichts zu sagen, da mein Windows nicht bootet, wenn ich das Hypervisor-Flag verstecke.
Bisher habe ich auch keine Sanktionen erlebt. Wobei die einzigen Online-Spiele, die ich spiele sind: Age of Empires 2 DE, Starcraft 2 und CoD Warzone. Auch liest man recht wenig über Banns in Verbindung mit VFIO. Zuguterletzt gibt es mittlerweile ja auch viele Anbieter virtueller Gaming-Rechner. Somit kann ein Publisher eigentlich nicht einfach jeden sperren, der eine VM nutzt.

Mapman schrieb:
Wenn ich es über Spice versuche, habe ich ja schon erzählt, dass ich normal Windows installieren kann und auch danach Änderungen vornehmen kann. Wenn ich die VM nun allerdings herunterfahre und wieder starten möchte, versucht Windows zu booten, hängt sich aber quasi auf. Die Ladepunkte während dem Starten verharren dann nämlich einfach in einer Position und auch nach längerem Warten tut sich nichts mehr.
Das heißt, der erste Start mit aktivem GPU-Passthrough funktioniert, der zweite allerdings nicht? Oder ist beides ohne GPU-Passthrough? Wie bekommst du die VM dann wieder gestartet?

Mapman schrieb:
Die CPU Last bleibt aber in geringen Maßen erhalten.
Wahrscheinlich ist sie fix auf einem bestimmten Wert und schwankt nicht in libvirt, oder?

Mapman schrieb:
Ohne Spice habe ich eben einfach nur einen Blackscreen auf dem zweiten Monitor, doch Last lässt sich auch hier ähnlich zum Spice Vorgehen bei meinem 1600er erkennen.
Okay, das klingt ziemlich nach dem Problem, was ich auch hatte. Die Last schwankt, oder? Das ist wichtig zu wissen, denn wenn sie fix ist, ist die VM höchstwahrscheinlich abgestürzt. Hast du die VM einfach mal 15 Minuten laufen lassen? Wie gesagt, bei mir kam das Bild dann von alleine und ich konnte den AMD Treiber installieren. Übrigens auch reproduzierbar. Ich habe den Treiber per DDU im Abgesicherten Modus mal gelöscht und musste dann nach einem Neustart wieder 15 Minuten warten, bis ich Bild hatte und den Treiber wieder installieren konnte.

Mapman schrieb:
Um zum Slotwechsel zu kommen: Ich habe bereits versucht, die Vega in Slot 2 und demnach die GT 710 in Slot 1 zu nutzen. Allerdings (unter nativem Windows 10 getestet) ist die Performance im 2. Slot nicht allzu gut. Meine Vermutung ist, dass die Ursache an einem PCI-E 2.0 Slot als 2. Slot liegt, kann mich aber natürlich auch irren.
Welches Mainboard hast du? Wenns ein AM4 ist: Auf den meisten Boards sind die ersten beiden Slots direkt per PCIe-v3 an die CPU angebunden. Wenn beide Slots genutzt werden, hat man an beiden Ports 8 Lanes. Daher sollte es eigentlich keinen Unterschied in der Performance machen. Und auch heute ist es ja noch immer so, dass 8x PCIev3 Lanes eine Grafikkarte nach wie vor nicht wirklich einbremsen. Aber ich kann auch nicht für alle existierenden Mainboards sprechen. :D

Zu Guter letzt: Magst du uns mal deine XML-Config zeigen? i440FX oder Q35 Chipsatz?
 
WilliTheSmith schrieb:
Das heißt, der erste Start mit aktivem GPU-Passthrough funktioniert, der zweite allerdings nicht? Oder ist beides ohne GPU-Passthrough? Wie bekommst du die VM dann wieder gestartet?
Genau, der erste Start funktioniert reibungslos, Graka wird erkannt, alles läuft erstmal wie gewohnt. Zum Testen habe ich dann eben die VM direkt heruntergefahren, weil ich noch ein Gerät hindurchgeben wollte. Beim nächsten Start dann eben der beschriebene Fehler, dass sich nichts mehr tut bee gleichbleibender CPU Last, ohne Schwankungen.
WilliTheSmith schrieb:
Okay, das klingt ziemlich nach dem Problem, was ich auch hatte. Die Last schwankt, oder? Das ist wichtig zu wissen, denn wenn sie fix ist, ist die VM höchstwahrscheinlich abgestürzt. Hast du die VM einfach mal 15 Minuten laufen lassen? Wie gesagt, bei mir kam das Bild dann von alleine und ich konnte den AMD Treiber installieren. Übrigens auch reproduzierbar. Ich habe den Treiber per DDU im Abgesicherten Modus mal gelöscht und musste dann nach einem Neustart wieder 15 Minuten warten, bis ich Bild hatte und den Treiber wieder installieren konnte.
Dieselbe gleichbleibende CPU Last habe ich auch ohne Spice, nur dort habe ich nicht mal ein Bild auf dem 2. Monitor, wenn ich die VM eben zum ersten Mal starte, kann aber gerne mal die VM starten und dennoch mal eine Stunde abwarten, ob sich etwas tut.
WilliTheSmith schrieb:
Welches Mainboard hast du? Wenns ein AM4 ist: Auf den meisten Boards sind die ersten beiden Slots direkt per PCIe-v3 an die CPU angebunden. Wenn beide Slots genutzt werden, hat man an beiden Ports 8 Lanes. Daher sollte es eigentlich keinen Unterschied in der Performance machen. Und auch heute ist es ja noch immer so, dass 8x PCIev3 Lanes eine Grafikkarte nach wie vor nicht wirklich einbremsen. Aber ich kann auch nicht für alle existierenden Mainboards sprechen. :D

Zu Guter letzt: Magst du uns mal deine XML-Config zeigen? i440FX oder Q35 Chipsatz?
Ich nutze das B350 Gaming Pro Carbon mit einem R5 1600, das hat auch wirklich einen PCI-E 2.0 Slot an zweiter Stelle, weswegen ich davon ausgehe, dass dieser am Performanceverlust liegt, wenn ich die Grafikkarten tausche. XML Konfig habe ich gerade nicht parat, aber ich nutze den Q35 Chipsatz.
 
@Mapman Okay, gleichbleibende CPU-Last spricht in der Regel dafür, dass sich das System aufgehängt hat oder abgestürzt ist. Bei schwarzem Bildschirm warten macht nur Sinn, wenn die Last schwankt, das System also was macht.

Der Q35 Chipsatz macht bei vielen Probleme. Oft geht es "nur" um ein unrund laufendes System, ich selber hatte aber schwerwiegendere Probleme. Was genau weiß ich allerdings nicht mehr, aber ein Bild aus der Grafikkarte gezaubert habe ich damit definitiv nicht. Vielleicht wäre der i440FX-Chipsatz die Lösung.
 
Ich werde heute und morgen noch mal ein paar Dinge ausprobieren, vor allem die, von denen hier berichtet wurde, wie z.B. von Q35 auf i440FX. Anschließend melde ich mich wieder mit ein paar neuen Erfahrungen. Des Weiteren möchte ich mich bei jedem bedanken, der mir hilft oder noch helfen wird, ist ja schließlich nicht selbstverständlich ^^
 
Kleiner Hinweis: Chipsatz umstellen ist nicht möglich. Du musst leider eine neue VM erstellen und Windows neu installieren. Zumindest habe ich das gelesen und selbst auch damals so gemacht.
 
Ich habe nun alles mögliche geteste und hatte leider immer noch keinen Erfolg. Ich bekomme kein Bild auf meinem zweiten Monitor, wenn ich die VM starte oder die VM lässt sich irgendwann nicht einmal mehr starten. Ich werde wohl oder übel auf einen Dual Boot umsteigen müssen, bis ich mit neuer Hardware mal wieder PCI Passthrough testen werden D:
 
Ich habe auch begeistert gelesen, dass AMD daran gearbeitet hat, dass die neuen Grafikkarten FLR und SBR problemlos beherrschen. Die Frage hatte gnif AMD auf Reddit gestellt und wurde zum Fall des NDA beantwortet. :) Thread und die wichtigen Posts von bridgmanAMD und gnif2
Fehlt nur noch eine käuflich erwerbbare RDNA2 GPU. :hammer_alt:

Bei einer Sache muss ich dich aber korrigieren: Der FLR-Bug ist in der Firmware der Grafikkarte. Ein Fix für alte Grafikkarten ist somit eher unwahrscheinlich.
 
Danke für die Korrektur, ich lerne immer gerne dazu! :)
Ich versuche mich übrigens gerade am Single-GPU Passthrough, falls das jemanden interessiert. Ich werde bestimmt nicht noch so einen ausführlichen Erfahrungsbericht schreiben, aber kann euch gerne darüber informieren ob und wie das funktioniert, vor allem mit dem vendor-rest von Gnif.
 
  • Gefällt mir
Reaktionen: Spliffy83
Ich hab' für den Moment leider aufgegeben. Man muss für Single GPU-Passthrough einen Skript schreiben, der die GPU von den Treibern löst und in der VM wieder einbindet und ich krieg' ständig Fehlermeldungen vom Kernel bzw. von amdgpu und das trotz vendor-reset. Außerdem hab' ich die letzten Tage viel zu viel Mühe in die Einrichtung einer VM mit meiner GTX 970 gesteckt, nur um dann festzustellen, dass PUBG und Rainbow Six: Siege wegen BattlEye in VMs nicht funktionieren, kriege weder Red Dead Redemption 2 noch Red Dead Online unter Linux zum Laufen und habe gerade gelesen, dass Red Dead Online wohl auch nicht in VMs läuft. Das war jetzt erstmal genug Gebastel für die vergangenen Tage und genug Enttäuschung von Spieleherstellern und der absichtlichen nicht-Unterstützung von Linux und virtuellen Maschinen. Da bleib ich wohl erstmal bei den Dingen, die funktionieren, CS:GO, GTA Online und Cyberpunk 2077..
 
Hallo Zusammen,

danke für den Bericht @Arjab! Ich habe das auch versucht und es klappte einfach mit mein Asus Strix X570-E Gaming und der Sapphire 5700 XT Pulse Grafikkarte nicht. Zum Testen habe ich eine Nvidia 1080 mal eingebaut und übergeben. Dies hat einwandfrei funktioniert nur nicht mit der 5700XT. Immer Fehler: 43

Ich habe alles mögliche probiert, jede freie Minute die letzten Tage. Ich war schon kurz vor dem Aufgeben! Aber nun habe ich es doch geschafft. Ich habe ein neues BIOS auf meine 5700XT geflasht dann klappte es. Aber ich kann nicht sicher sagen ob es wirklich am BIOS der GPU lag, denn ich habe auch das BIOS vom Board upgedatet und dabei wurde "ReSize BAR" (für AMD SAM) deaktiviert. Sobald ich dies aktiviere, klappt zwar die Übergabe der 5700XT aber nur mit Fehler: 43

Komischerweise ist es bei der XFX-Nvidia 1080 Karte egal ob SAM aktiviert ist oder nicht.


Wollte das nur mitteilen, denn das kostete mich wirklich jede freie Minute der letzten zwei Wochen! Ich habe auch noch nichts im Internet mit der 5700XT und SAM bei PCI-Passthrough gelesen.

Aber jetzt klappt es mit der 5700XT und 1080. Denke, dass die 5700XT schon ein kleiner Sonderfall ist. Also unbedingt bei der 5700XT SAM deaktivieren!

Gruß johno


PS.: Sobald ich SAM im Bios aktiviere habe ich wieder Fehler: 43. Also denke ich, dass eher SAM mit der 5700XT ein Problem für PCI-Passthrough ist.

PPS.: vom Reset-Bug bin ich bei der 5700XT auch betroffen aber mit dem Vendor-Reset Modul ist das so gut wie kein Thema mehr!
 
Zuletzt bearbeitet:
Hi Leute,

@lokon: danke für die Info! Sehr interessant. Nein das hatte ich nicht gefunden ;-)
@Arjab: gern geschehen. Ich habe kein Problem aktuell, alles funktioniert, seit dem dass ich "resizable BAR" deaktiviert habe -im BIOS. :-)

Ich wollte euch das nur mitteilen, weil ich wirklich schon fast verzweifelt bin und im Internet nichts darüber gefunden habe. Jede Lösung, jedes Problem traf nicht auf mich zu. Bei mir war das Problem, dass ich "resizable BAR" im Bios aktiviert hatte und es deswegen nicht funktioniert hat (wohlgemerkt nur mit er 5700XT nicht, mit der Nvidia 1080 schon).

Viele Grüße
johno


PS.: und ja, ich habe bei deinen genannten Links geschaut. Nur bekam ich im Log auch keine Fehlermeldung ala: "vfio-pci 0000:09:00.0: BAR 3: cannot reserve [mem 0xf0000000-0xf1ffffff 64bit pref]" etc. Ich nutze auch ARCH-Linux als Hauptsystem. Aber egal, jetzt läuft alles und bei mir war es: "resizable BAR" im BIOS (vielleicht auch noch dazu mein Bios der 5700XT). Habe die Karte mit diesem hier geflasht.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Xenophon61
Just registered (with the help of Google translate) to say THANK YOU all for this thread, especially Arjab and johno!

I've been trying for months to passthrough an MSI 5700XT to my MSI B450-A Pro Max running Manjaro (5.9, with vendor-reset installed), and all I was getting was the code 43 error.

Disabling the "resizable BAR" option in the BIOS did it!

But it's not just that, I had a great time reading and learning from all of you.

Once again, thanks!

With greetings from Athens,

Xen
 
  • Gefällt mir
Reaktionen: Arjab, s0ja und johno
Zurück
Oben