grazzolini
commented
4 years ago I have done a new round of testing in light of recent mesa updates and also new 5.8 kernel. Here are the results:
When using nvidia prime render offload:
linux 5.8.0: The VM boots, no BIOS is displayed (with or without the MESA_LOADER_DRIVER_OVERRIDE workaround), only the output from the early userspace onward is shown. When trying to starting X though, qemu will segfault and the machine will be stopped.
I've tested both kernel 5.8 and 5.4 on the guest and it seems the kernel that is running on the guest doesn't matter for reproducibility of this issue.
linux 5.4.57: The VM boots, no BIOS can be seen (with or without the MESA_LOADER_DRIVER_OVERRIDE workaround) , and X starts, but then the machine hangs on 100% CPU and needs to be destroyed. Once again, the kernel running on the guest seems to play no part in what happens.
When using bbswitch + bumblebee:
linux 5.8.0: The VM boots and X can be started normally. Even the BIOS can be seen (with MESA_LOADER_DRIVER_OVERRIDE workaround). But, if the VM is stopped and the host is suspended, the VM cannot be started again, it stays stuck right after loading the initramfs (when it loads the i915 module). Again, the kernel being ran on the guest plays no part on this. Tried both 5.8.0 and 5.4.57.
linux 5.4.57: It's the only combination that works flawlessly. For not getting garbled graphics, the MESA_LOADER_DRIVER_OVERRIDE workaround is needed. But, the host can be suspended, after the VM is stopped, and when resuming the host, the VM can be started again.
Suspending the host while the VM is powered on never worked properly for me regardless of kernel version, or if using prime render offload or not. The VM would either crash when the host would be suspended or X would crash on the guest VM.
rnd-ash
TinaZhangZW
rugubara
evelikov
WhyDoWeWonder
This comment was edited
I have started using intel gvt-g a few months ago and, at the time, I was also using nvidia prime render offload method for offloading to the nvidia card. I had issues getting gvt-g to work on any recent kernel (> 5.5), but I had success using the 5.4 lts branch on Arch Linux.
Very recently, however, with the advent of the version 5.4.51 of the lts kernel, as well the mesa 20.1.3 update, my vm with gvt-g would load normally and when X would get started, it would hang, causing 100% cpu usage on one of the hosts CPU's with a blank screen.
Reverting things to kernel 5.4.50 and previous mesa, didn't seem to work. This is where a recent nvidia update, 450.57 comes in. It was the responsible for this new behavior of making my VM to hang.
During my investigations, I've found out that, if using nvidia prime render offload, the VM using the virtualized intel card would work, up until the previously mentioned versions of the software, but, it would not display the mouse pointer properly and also, I would only be able to see the boot from early userspace onward, no POST, no bootloader, nothing.
So, I've done a few experiments with using bbswitch to keep the nvidia card not only powered off, but also to prevent nvidia modules to be loaded, making sure prime render offload is not used. That gave me garbled graphics as in #152. So, I have added the
Also, I'm able to run with gvt-g on the latest mainline kernel, 5.7.8, without any issues. As long as I'm not using the prime render offload method, everything works. I have no idea why this interferes with the virtualized card, but my bet is on some weird mesa/xorg issue.