It's pretty great and has been useful for many use cases for me, except too bad it lacks good 3D graphics support for modern gaming
QEMU v4.0.0 released
141–150 of 168 posts
Re: QEMU v4.0.0 released
#142Re: QEMU v4.0.0 released
#143It's pretty great and has been useful for many use cases for me, except too bad it lacks good 3D graphics support for modern gaming
It all depends on how and if someone will implement a Windows driver for VirGL. Given how complex video drivers are nowadays, it looks like a pretty daunting task.
Re: QEMU v4.0.0 released
#144Last week, I intended to replace VirtualBox with QEMU for my personal use. The spartiate documentation made it really hard. I lack the competence to seriously contribute. The official documentation just explains the numerous parameters. It also points to tutorials (wikibook, etc), which unfortunately are very basic and out of sync. Even Arch Linux does not provide a good documentation (lack of clarity, some obsolete…
In the end we rolled our own solution that is much more lightweight, uses QEMU directly and provides better visibility, ease of use and even some potentially useful networking features. Here are a few screencasts [1].
This is mainly designed as a module for Flockport and we will preview this soon.
Re: QEMU v4.0.0 released
#145LTT [1] did a video recently about running macOS on a Linux host using QEMU. Anyone here tried that? If so, what's the experience like? Thanks [1]: https://www.youtube.com/watch?v=ATnpEOo3GJA
I had success getting macOS running on QEMU with my existing PC, but its performance suffered without a dedicated GPU and CPU pinning, which my new build will be configured to handle
Re: QEMU v4.0.0 released
#146Earlier quoted context omitted.
Thats sounds pretty interesting. Ive been running a hacked together windows VM gaming setup via qemu with vfio passthrough for the past 1.5 years on my local linux server. Im pretty pleased with it. Ive got it down to simply executing a small script and everything comes up. It could be even more automated using evdev potentially (recognizing mouse/keyboard events). I was thinking about expanding the setup to include…
I don't have any specific guides about my setup, but here are a few things that have been helpful to me: - Good starting point for setting up macOS under QEMU/KVM: https://github.com/kholia/OSX-KVM - DSDT/SSDT patching: https://www.tonymacx86.com/threads/ssdt-gpu-graphics-card-in... - AMD reset bug: https://www.reddit.com/r/VFIO/comments/5h351m/gpu_stuck_in_d... - Kernel extension that can help with some GPU issues:…
Re: QEMU v4.0.0 released
#147Earlier quoted context omitted.
I don't have any specific guides about my setup, but here are a few things that have been helpful to me: - Good starting point for setting up macOS under QEMU/KVM: https://github.com/kholia/OSX-KVM - DSDT/SSDT patching: https://www.tonymacx86.com/threads/ssdt-gpu-graphics-card-in... - AMD reset bug: https://www.reddit.com/r/VFIO/comments/5h351m/gpu_stuck_in_d... - Kernel extension that can help with some GPU issues:…
In case anyone runs across similar AMD GPU issues, the "disable_idle_d3=1" option in the second pastebin link (when used as a kernel parameter) should be prefixed as "vfio-pci.disable_idle_d3=1". Even then, it can still be hit-or-miss with some cards (it works most of the time for me, but some VM restarts still find that the GPU has entered D3 and won't come back without rebooting the host).
Re: QEMU v4.0.0 released
#148Anybody here using QEMU? What is your use case?
Mainly playing with old operating systems, I'm a retrocomputing enthusiast. While years ago I would mainly use Virtual PC (I do miss its great GUI) and VMWare (and rarely bochs), qemu improved a lot and has (somewhat decent) support for so many more architectures. You can run Solaris for SPARC and Mac Os 9, for example.
Link?
Re: QEMU v4.0.0 released
#149LTT [1] did a video recently about running macOS on a Linux host using QEMU. Anyone here tried that? If so, what's the experience like? Thanks [1]: https://www.youtube.com/watch?v=ATnpEOo3GJA
Re: QEMU v4.0.0 released
#150Earlier quoted context omitted.
In case anyone runs across similar AMD GPU issues, the "disable_idle_d3=1" option in the second pastebin link (when used as a kernel parameter) should be prefixed as "vfio-pci.disable_idle_d3=1". Even then, it can still be hit-or-miss with some cards (it works most of the time for me, but some VM restarts still find that the GPU has entered D3 and won't come back without rebooting the host).
is this a macOS guest specific issue? would I have similar issues on a Windows or Linux guest?
Previously, I also attempted using a kernel patch that's been floating around (DECLARE_PCI_FIXUP_HEADER ... quirk_no_bus_reset), but it just gives me corrupt graphics when rebooting the VM.