Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VirGL – A virtual 3D GPU for use inside QEMU virtual machines

docs.mesa3d.org

Post reply on HN
Print view View original

51–60 of 84 posts

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#51

Post by RealStickman_ »

gary17the wrote: post #24
denkmoon wrote: post #22

Earlier quoted context omitted.

Except that requires IOMMU which is not always available nor is it always reliable on consumer motherboards.

Good point, but I believe that was a serious problem 10 years ago, while these days virtually any decent motherboard properly supports IOMMU, consumer-grade boards included - e.g. any Asus motherboard should work perfectly.

They might support IOMMU, but the default groups can be very annoying to work with so you have to use a patched kernel as well that "ignores" the actual groups.

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#52

Post by Arch-TK »

codedokode wrote: post #43
throwaway698585 wrote: post #31

VirGL is a poor solution to the pressing problem of virtualized graphics. It only really exists because the hardware makers AMD/Intel/Nvidia in their infinite greed refuse to support VFIO on all GPU's like how IOMMU is supported on nearly all CPU's.

Isn't it dangerous to give a guest direct access to a GPU?

It's not really to different to giving your web browser access to your GPU (and by extension to random websites using WebGL). So yes, it's dangerous. But it is at least a threat which designers of GPUs are already considering. Although there have been interesting bugs where GPU memory hasn't been zeroed before allocating it to a new context and you could read previously written graphics memory to find secrets.

As long as 1 GL context on the guest side == 1 GL context on the host side then it _should_ at least be as safe as letting your web browser access your GPU but certainly not as safe as using an IOMMU to segregate a whole GPU solely for your VM.

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#53

Post by some-natalie »

throwaway698585 wrote: post #31

VirGL is a poor solution to the pressing problem of virtualized graphics. It only really exists because the hardware makers AMD/Intel/Nvidia in their infinite greed refuse to support VFIO on all GPU's like how IOMMU is supported on nearly all CPU's.

That's 100% fair. Good thing it's not too difficult to assign VFIO w/i QEMU for virtual machines despite the manufacturer shenanigans. :)

The Arch wiki has a great guide here - https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM...

It does get a little tricky if your GPUs are identical, but I've done this for years and maintain a guide for doing this (as well as the ACS-override patched kernel RPMs) for Fedora.

- Writeup - https://some-natalie.dev/blog/fedora-acs-override/

- Code + RPMs - https://github.com/some-natalie/fedora-acs-override

As far as concerns around stability with ACS override, I tend to only enable the override for the specific GPU (or other hardware) that I'm passing through and haven't encountered any stability problems or memory leaks that'd interrupt desktop or light server usage. I also used to run this for a bunch of white-box GPU hardware for a customer at a former job and it worked well for exploratory AI/ML workloads before investing in the big Nvidia DGX boxes. YMMV, of course!

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#54

Post by galangalalgol »

some-natalie wrote: post #53
throwaway698585 wrote: post #31

VirGL is a poor solution to the pressing problem of virtualized graphics. It only really exists because the hardware makers AMD/Intel/Nvidia in their infinite greed refuse to support VFIO on all GPU's like how IOMMU is supported on nearly all CPU's.

That's 100% fair. Good thing it's not too difficult to assign VFIO w/i QEMU for virtual machines despite the manufacturer shenanigans. :) The Arch wiki has a great guide here - https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM... It does get a little tricky if your GPUs are identical, but I've done this for years and maintain a guide for doing this (as well as the ACS-override patched kernel RPMs) for Fedo…

Is there a reason an emulator like qemu couldn't just pass along spirv like wasm does with webgpu? Would that be way slower?

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#55

Post by londons_explore »

bilegeek wrote: post #16

Note also: it just got an experimental Windows driver! [1] https://github.com/virtio-win/kvm-guest-drivers-windows/pull...

> disables preemption systemwide

I guess that means not usable day-to-day. One infinite loop in any app and the whole OS will freeze forever. I didn't even know any modern OS could operate only with cooperative multitasking. Windows 3.1 in 1992 and PowerPC Mac OS until 2002 were the last mainstream OS's to use it...

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#56

Post by londons_explore »

Arch-TK wrote: post #52
codedokode wrote: post #43

Earlier quoted context omitted.

Isn't it dangerous to give a guest direct access to a GPU?

It's not really to different to giving your web browser access to your GPU (and by extension to random websites using WebGL). So yes, it's dangerous. But it is at least a threat which designers of GPUs are already considering. Although there have been interesting bugs where GPU memory hasn't been zeroed before allocating it to a new context and you could read previously written graphics memory to find secrets. As lon…

I feel like a good half of machines I find with glitchy graphics drivers seem to show bits of textures from one application inside another application - indicating memory contents leakage between contexts. Chunks of webpages from Chrome appearing in 3D games seems common.

And those are accidentally caused leaks. As soon as someone starts storing actually sensitive data in graphics memory, I'm sure lots of methods to deliberately cause leaks will be found.

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#58

Post by zbrozek »

codedokode wrote: post #43
throwaway698585 wrote: post #31

VirGL is a poor solution to the pressing problem of virtualized graphics. It only really exists because the hardware makers AMD/Intel/Nvidia in their infinite greed refuse to support VFIO on all GPU's like how IOMMU is supported on nearly all CPU's.

Isn't it dangerous to give a guest direct access to a GPU?

Security isolation isn't the only possible goal of virtualization.

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#59

Post by vGPU »

londons_explore wrote: post #55
bilegeek wrote: post #16

Note also: it just got an experimental Windows driver! [1] https://github.com/virtio-win/kvm-guest-drivers-windows/pull...

> disables preemption systemwide I guess that means not usable day-to-day. One infinite loop in any app and the whole OS will freeze forever. I didn't even know any modern OS could operate only with cooperative multitasking. Windows 3.1 in 1992 and PowerPC Mac OS until 2002 were the last mainstream OS's to use it...

I believe he’s referring to GPU preemption. I don’t think it’s even possible to disable cpu preemption on windows. On nix you can.

Re: VirGL – A virtual 3D GPU for use inside QEMU virtual machines

#60

Post by vGPU »

some-natalie wrote: post #53
throwaway698585 wrote: post #31

VirGL is a poor solution to the pressing problem of virtualized graphics. It only really exists because the hardware makers AMD/Intel/Nvidia in their infinite greed refuse to support VFIO on all GPU's like how IOMMU is supported on nearly all CPU's.

That's 100% fair. Good thing it's not too difficult to assign VFIO w/i QEMU for virtual machines despite the manufacturer shenanigans. :) The Arch wiki has a great guide here - https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM... It does get a little tricky if your GPUs are identical, but I've done this for years and maintain a guide for doing this (as well as the ACS-override patched kernel RPMs) for Fedo…

A better way [for me, anyways] is getting GRID drivers running. However, this only works with the 9xx cards up to the 2080.

https://gitlab.com/polloloco/vgpu-proxmox

Post reply on HN