QEMU with VirtIO GPU Vulkan Support

https://gist.github.com/peppergrayxyz/fdc9042760273d137dddd3e97034385f

by GalaxySnail • 2 years ago

239 50 2 years ago

gist.github.com

cwbriscoe2• 2 years ago

Unfortunately my distro is at linux version 6.8. Looking forward to trying it out someday.

gpm• 2 years ago

Switch distros?

cwbriscoe2• 2 years ago

Well 6.13 is bleeding edge, it just started it's RC cycle. I can wait until it is mainline.

eptcyka• 2 years ago

Unfortunately, ZFS doesn't support anything stable beyond 6.6.

SirGiggles8• 2 years ago

What do you mean by stable? 2.2.7 supports the 6.12 kernel if I'm not mistaken

rafaelmn• 2 years ago

So this seems to be about enabling a Linux VM use Vulkan on a Linux host qith Vulkan support ?

shatsky• 2 years ago

This seems to be about possibility to enable Vulkan in any guest OS for which virtio-gpu guest driver will be developed. For Windows https://github.com/virtio-win/kvm-guest-drivers-windows/pull... is being developed, hopefully it will take off

jamesu• 2 years ago

It's nice to see support for vulkan in qemu actually getting somewhere, being able to run modern accelerated workloads inside a vm (without dealing with sr-iov) is pretty cool and definitely has some use cases.

shmerl2• 2 years ago

Looking forward to KDE Plasma implementing Vulkan rendering and then it would run in qemu/kvm with GPU acceleration over Vulkan rather than OpenGL.

rescbr• 2 years ago

You can use Zink (https://docs.mesa3d.org/drivers/zink.html) to translate OpenGL to Vulkan.

I have even used it in Windows to make a legacy proprietary OpenGL application work properly with recent Windows versions + a mobile (now unsupported) AMD GPU.

shmerl2• 2 years ago

I use Zink for some games that rely on OpenGL since it works better with Mangohud as a Vulkan layer. For example all games that need scummvm or dosbox.

doctorpangloss• 2 years ago

Does this mean graphics workloads using Vulkan can be isolated and share most GPUs securely?

kcb• 2 years ago

Don't think there's anything particularly secure about it.

stracer2• 2 years ago

If malicious program has access to GPU directly or via some buggy interface, the whole system is at risk. There is no "safe" GPU virtualization like there is with CPUs.

jakogut• 2 years ago

Features like this are why I prefer using QEMU directly rather than an abstraction like libvirt on top of QEMU.

Graphical interfaces like virt-manager are nice at first, but I don't need an abstraction on top of multiple hypervisors to make them all look superficially the same, because they're not. Eventually the abstraction breaks down and gets in the way.

I need the ability to use the full capability of QEMU. I'll write a shell script to manage the complexity of the arguments. At least I don't have to deal with XML, validation, and struggling with enabling the options I want that are only supported by one specific emulator, which libvirt doesn't support, because it's not common to all of the backends.

iforgotpassword2• 2 years ago

I use libvirt for qemu, because I got tired of rewriting my command line every two days because the options changed yet again.

stracer2• 2 years ago

Yeah, why do they change options so often. They should keep some backward compatibility, qemu is not a new project.

exceptione3• 2 years ago

How do you deal with networks?

I like it that libvirt integrates with firewalld. libvirt via virt-manager also provides you with quick options for dns.

My fear is that this would be a lot of wrangling with qemu before I get there. I am not fond of virt-manager, the UI is clunky, but for setting up a machine it is really helpful.

dijit• 2 years ago

Depends on the kind of network you want.

Personally I'm very lazy, so I just make a virtual bridge and force QEMU to use it for everything; putting all my VMs on my local network.

I totally understand that not everyone can do this, which is why I asked the question, I'd be interested in exploring how you would prefer the network topology to look like.

Having a virtual network on a machine would mean having a dns/dhcp server (I think dnsmasq can actually do both by itself) for ease of use, but I think I could give you a 5 line bash script that could do basically what you want easily, depending on what it is you want.

The normal "internal" network topology ends up giving you an outbound NAT to the local network (to, eventually, get onto the internet) which, I personally really dislike.

throwaway484763• 2 years ago

This isn't SR-IOV which is a hardware feature for virtualizimg GPUs. The problem is the OEMs that gate this feature for enterprise products. Few people buy them so the state of the software ecosystem for virtual GPU is terrible.

0xcde4c3db• 2 years ago

You don't even necessarily get it with enterprise products; last time I checked, Nvidia requires additional CAL-type licenses installed on a "certified" server from the "Nvidia Partner Network", while AMD and Intel limit it to very specific GPU product lines targeted at VDI (i.e. virtualizing your employees' "desktops" in a server room a la X/Citrix terminals).

mysteria• 2 years ago

Intel used to have GVT-g hardware virtualization on their integrated GPUs from Broadwell up. I haven't tried it myself but know people who used and liked it then. All good things come to an end though, and Intel scrapped it for Rocket Lake.

I would've gone and bought Intel ARC dGPUs for my Proxmox cluster if they supported hardware virtualization on their consumer line.

https://wiki.archlinux.org/title/Intel_GVT-g

SirGiggles8• 2 years ago

12th gen and newer had some form of SR-IOV support in the i915 driver, but I'm not sure whether or not Intel fully upstreamed that.

Here's a project that, iirc, backported and made a DKMS for from Intel's tree: https://github.com/strongtz/i915-sriov-dkms

I also recall from that time that Intel had SR-IOV code for the iGPU (and I think their dGPUs) in the new Xe driver

jeroenhd• 2 years ago

My experience with GVT-g is that it mostly served as a kernel panic generator. A good idea, but the software experience just isn't stable enough.

C-x_C-f• 2 years ago

Ignorant question—how's this different from qemu-virgl? I've been using the latter (installed from homebrew) for the last few years passing --device virtio-vga.

SirGiggles8• 2 years ago

Virtio-GPU Venus is similar to Virgl except it passes through Vulkan commands rather than OpenGL

crest• 2 years ago

At that point just run the code inside a chroot with a full /dev and call it good enough. No common GPU driver, firmware or hardware was designed to securely run really untrusted code from multiple tenants.

mappu• 2 years ago

WebGL / WebGPU are a somewhat safe subset. Or at least safe enough that Google will keep funding multi-million pwn2own bounties for Chrome with WebGL / WebGPU enabled.

sim7c00• 2 years ago

big bounties says nothing about security.

zamadatix• 2 years ago

The "Linux hosts Linux" case does seem the least interesting for that reason. I hope one day this results in actually usable acceleration of hosting a windows VM.

xrd• 2 years ago

Does this mean you can run cuda applications inside a qemu VM? The equivalent to --gpu=all for docker but now in an isolated VM? Is this permitting sharing of the GPU inside a VM?

SirGiggles8• 2 years ago

I think this would depend on Virtio-GPU Native Context which, if I recall correctly from the qemu-devel mailing list, is the next natural progression from Virtio-GPU Vulkan

Edit: Can't substantiate further, but this is what Huang Rui, the prior steward of the Venus patchset, said: https://lore.kernel.org/all/20240411102002.240536-1-dmitry.o...

Edit 2: For further clarity, Virtio-GPU Native Context would permit running the native GPU drivers (with some modifications, minimal is what I remember being claimed) inside a VM

throwaway484763• 2 years ago

It's going to be significant slower than native performance. Same as VirGL.

enoeht• 2 years ago

One still needs an extra discrete vulkan gpu for it and the other for running the OS?

iforgotpassword2• 2 years ago

You just need any GPU with Vulkan support in the host system, which is very likely to be the case nowadays (except maybe in servers).

nubinetwork• 2 years ago

Someone wake me up when libvirt/virt-manager supports it, because i can't get the regular virtio gpu acceleration working either... something something spice doesn't support it...

QEMU with VirtIO GPU Vulkan Support

Related Stories