[HN Gopher] Venus on QEMU: Enabling the new virtual Vulkan driver
___________________________________________________________________
Venus on QEMU: Enabling the new virtual Vulkan driver
Author : farmerbb
Score : 115 points
Date : 2021-11-28 07:15 UTC (15 hours ago)
(HTM) web link (www.collabora.com)
(TXT) w3m dump (www.collabora.com)
| bonzini wrote:
| KVM maintainer here, is there a report of the EFAULT issue with
| AMD processors?
| zbrozek wrote:
| I love watching the QEMU ecosystem develop. I use it for running
| a handful of VMs on a host server: a Windows machine to run my
| label printers and their terrible software, opnsense to be my
| router, and then a couple test beds that I use to try new
| software in a clean environment.
|
| Someday maybe it'll be possible to accelerate guest Windows
| DirectX graphics without hardware support for SRIOV. That'll be
| great for my CAD workloads.
| devit wrote:
| Is this secure? (i.e. does this prevent a malicious VM from fully
| taking over the host, writing arbitrary GPU memory, reading
| arbitrary GPU memory, corrupting other GPU memory or state,
| crashing the GPU)
|
| Apparently the web people decided to create WebGPU instead of
| adopting Vulkan in part due to security issues, and I see no
| mention of security on the Mesa documentation.
| badsectoracula wrote:
| My understanding of WebGPU isn't that it was adopted over
| Vulkan due to security issues but because Apple (who
| essentially designed it) doesn't want to touch anything related
| to Khronos due to some litigation between them. Which is
| probably why WebGPU is made under W3C instead of Khronos (who
| made WebGL).
| seoaeu wrote:
| That was the alleged (but false) reason they picked WGSL over
| SPIR-V, not the justification for designing WebGPU. Vulkan's
| C API isn't really compatible at all with JavaScript and has
| memory safety concerns and so forth. WebGPU has a slightly
| restricted, but vastly nicer interface. Plus there are a
| bunch of downsides to require browsers to emulate Vulkan over
| DirectX or Metal.
| flohofwoe wrote:
| Security definitely played the biggest role in WebGPU's
| design process. The other goal was identifying the common
| feature set of D3D12, Metal and Vulkan. The resulting API is
| the result of those two goals.
|
| (disclaimer: I haven't been part of the WebGPU design
| process, only followed it closely through the publicly
| available meeting notes and discussions).
| sheepdestroyer wrote:
| Apple is so toxic for the ecosystem. This is Oracle level
| unpleasantness.
| IntelMiner wrote:
| The difference is they've gone from being a niche nobody
| making contrarian decisions like Firewire over USB to a
| market trend setter removing headphone jacks and adding
| phone notches
| simondotau wrote:
| When did Apple choose FireWire over USB? Apple has never
| shipped a computer with FireWire which did not also have
| USB.
| IntelMiner wrote:
| Apple was one of the pioneers of Firewire originally
| wanting to replace ADB with it
|
| They never "left out" USB but they strongly preferred
| Firewire and their devices (such as the original iPod)
| came in Firewire first
| wmf wrote:
| The iPod used Firewire because it would have taken ages
| to sync using USB 1.x.
| indymike wrote:
| There was a period in time where Macbooks had FireWire
| 800 and USB 2. Apple chose not to be first with USB 3, so
| the choice was more expensive, fast FireWire or cheap and
| slow USB 2 devices. FireWire was significantly faster
| than USB 2, USB 3 was faster than FireWire. Eventually
| Apple dropped FireWire completely, and added Thunderbolt
| connectors. That did anger quite a few people who were
| invested in expensive FireWire devices. My favorite
| Macbook Pro was a 2015 13" it had USB 2 ports and two
| thunderbolt ports for high speed devices. Honestly, the
| only thing I ever used the thunderbolt port for was
| driving extra displays.
| kitsunesoba wrote:
| Things have improved by now, but my experience with the
| earlier USB 3 devices is that compared to their FireWire
| counterparts they were extremely flaky -- wildly
| inconsistent transfer rates, intermittent disconnections,
| and general weirdness, especially for sustained
| workloads. I could see FireWire being preferred over USB
| 3 for that alone, even if USB 3 was faster on paper.
| smoldesu wrote:
| My experience with Firewire was that not a single
| peripheral I owned was compatible. So yeah, I probably
| would have preferred a few more USB ports instead of a
| dedicated plug for the iPod I don't own.
| monocasa wrote:
| I wouldn't consider any qemu based vmm a security boundary. I
| think of VM code as running with the same permissions/access as
| the qemu process itself.
| my123 wrote:
| It's no more secure than the security isolation guarantees
| given by the GPU driver stack to a regular process. No more
| guarantees are provided than that.
|
| I'd consider the VMM as even more untrusted than before when
| VirGL is used, with always assuming that the guest has code
| exec in the VMM. With all the implications that this entails.
___________________________________________________________________
(page generated 2021-11-28 23:02 UTC)