> Frankly, it isn't meant for developers, either. Almost every page on that site is either woefully incomplete, or crib notes from docs/talks, which is fine for

> Frankly, it isn't meant for developers, either. Almost every page on that site is either woefully incomplete, or crib notes from docs/talks, which is fine for a high-level overview, but it's not an API reference developers can use either. The sample code is mostly just lifted from other places (such as https://github.com/torvalds/linux/blob/master/samples/vfio-m https://github.com/torvalds/linux/blob/master/samples/vfio-m...), so useless you're better off reading the source (https://openmdev.io/index.php/OpenRM https://openmdev.io/index.php/OpenRM), or just links to other people's APIs which interested devs can find. Well, the Mediated Device Internals article does cite every piece of information used but it's still incomplete. I made that page because it's largely a collection of everything I've learned while developing software. The "lifted" samples literally have the authors at the top of every header and the original link is the first line beneath the title in the README.md: https://github.com/OpenMdev/VFIO-Mdev_Samples https://github.com/OpenMdev/VFIO-Mdev_Samples > I'm not confused either about how GVM/mdev-gpu works or about its relation to libvf.io. It's not hard to read between the missing lines of your project roadmap. You define types that are presented in mdevctl via a YAML config file the user can write themselves or via a JSON file. So LibVF.IO might as well be entirely ignorant to the fact that GVM is on the system. All it sees are different arbitrary mdev types that the user decides to create. Not sure where you're going with this comment. >I read this before I ever wrote a reply, which you should have guessed because there was no other way to get any information. None of it tells anyone WHY this should use this instead of the bindings which have 100 developers on them, which have been battle tested for years, and for which the original author of VFIO wrote exhaustive, excellent manuals on the blog I linked earlier 7.5 years ago. >What advantages does your system offer? Well for starters I've never argued LibVF.IO is better than libvirt. In-fact when folks bring it up I generally say there's a lot we can learn from libvirt. GVM/Mdev-GPU isn't LibVF.IO so I'm kind of blown away that you keep bringing that up as if they're the same. GVM/Mdev-GPU controls which types the vendor driver presents to mdevctl - GVM/Mdev-GPU is neither an mdevctl replacement nor does it share code with or even integrate with LibVF.IO. I don't think you really grasp that. GVM/Mdev-GPU enables the creation of arbitrary mdev types against the Nvidia driver as defined by the user. Those types generally have "capabilities" restricted by arbitrary policy and "available mdev types" are stored in an XML file alongside signatures which attempt to stop the user from defining their own types. GVM/Mdev-GPU gives control back to the user. Also our codebase is GPLv2 and we don't enforce any kind of "device-specific" restrictions. Nvidia's equivalent is closed source and intentionally locks out consumer cards. >I did read that. There's nowhere else I would have said "Haskell bindings to RMAPI". I didn't call it anything else because it doesn't manage any other kind of mediated device, it's a pretty thin shim, and there's no real way to suss out what it's doing other than reading the code or the autogenerated module docs, which don't actually tell any developers where to get the values they need to populate it, which they can only get by reading other API docs (not yours), and if they're going to do that, they may as well just write their own in a language they like better. It's unclear what you mean by a "thin shim". Yes, I agree we do need to document how to use it better. >It's not clear from the outset what the advantage is over just submitting a PR to mdevctl to echo into /sys/devices/..../[create|remove], and overall, the README doesn't give any information about it whatsoever, even `--help` output to show the args and defaults. mdevctl is a bash script for echoing values. GVM/Mdev-GPU is creating the available virtual functions that mdevctl sees underneath it (a layer lower). I hope that clears that up. > This does not answer the question at all of "why not libvirt?" You can. I think I've covered that LibVF.IO isn't the only thing that works with GVM/Mdev-GPU. You can use Libvirt or whatever you like. It's completely agnostic. > It's unrelated... for now. And there is zero reason to use this instead of libvirt hooks which were written by and are tested by teams which already do this for libvirt (which virsh and virt-manager are just interfaces to anyway). Okay, how about you can't create your own mediated device types? You're confined to those that Nvidia generously offers to you with arbitrary restrictions on their "capabilities" - "capabilities" which you have to differently pay for to virtualize your own GPU - A GPU I will remind you which is entirely restricted to their enterprise product lineup and artificially locks out consumer GPUs. When the user can define their own mdev types it puts them in control of how they can virtualize their own GPUs. If you want to use mdevctl on top of GVM/Mdev-GPU or Libvirt or anything else there's absolutely nothing stopping you. We also aren't stopping you from using your normal person consumer GPU (the kind most people own). > It is unlikely in the extreme that the current state of GVM will work for anyone else's use case, primarily because "give me the UUIDs of existing devices" is already handled by walking /sys, and creating a new one of a given type (or removing it on VM shutdown) in more or less the same way. "Give me the UUIDs of existing devices" is not what GVM/Mdev-GPU does. It allows the user to create their own arbitrary mdev types. That has no connection at all to "give me the UUIDs of existing devices" or creating a new one of a given type or removing it on VM shutdown. This is literally defining the mdev types that are presented by the vendor driver and seen by mdevctl. It has nothing to do with what you just said.