ARArcVRArthur·Jul 6, 2022
> That said, a link to how mdev internals work isn't useful to end-users, who just want to know "how do I partition my card"? As-in "which driver/utilities do I need to install"?
OpenMdev.io is meant for developers, not for users.
> Is there some way in which LibVF.IO differs from just being a wrapper around KVM/qemu?
No, it's a Libvirt alternative with convenience functions for VFIO users. Here's the documentation:
https://openmdev.io/index.php/LibVF.IO
>"defines available mdev devices in the mdevctl list" only as a side effect of the fact that it's doing a whole bunch of other stuff to the system.
GVM/Mdev-GPU is unrelated to LibVF.IO which I think is where you're getting confused. LibVF.IO does not actually have any integration with GVM/Mdev-GPU so if you're reading that code you're not going to learn how GVM/Mdev-GPU works. We're plan
Read the rest
ning to integrate the two but it's not done yet.
GVM/Mdev-GPU creates the mediated devices that are exposed in the mdevctl list. Read this code instead:
https://github.com/Arc-Compute/Mdev-GPU/
>Similarly, it strongly appears that arcd could be more or less replaced by any given binding to the libvirt API, which would also allow the VMs to be easily migrated (assuming identical hardware), the libvirt XML shared with others, snapshotting, storage pooling, listed in virt-manager/virsh, and so on.
Sure, arcd is a reference Virtual Machine Monitor as it says at the top of this page:
https://openmdev.io/index.php/LibVF.IO
It's actually unrelated to GVM. You can use GVM with whatever you want, including Libvirt/Virsh/Virt-Manager because we wanted to support users of those things with GVM rather than requiring that they use LibVF.IO.
> GVM, rather than "a GPU Virtual Machine ..." is Haskell bindings for the RMAPI.
Well, we do create mediated devices exposed in mdevctl defined by a user config file, so I would say it goes a fair amount beyond Haskell bindings for the RMAPI.
I think it's reasonable to describe a GPU mediated device as a virtual GPU given you get a virtual function that represents a scheduling share and virtual BAR space with a share of the device VRAM (partition of the GPU) which you can pass to one or several guests to allow them to run an unmodified guest GPU driver. I can't really think of a better definition for a vGPU. The Mediated Device Internals article pretty much explains the APIs GVM is dealing with - I believe we even link some sample code:
https://openmdev.io/index.php/Mediated_Device_Internals
Your comment seems kind of trollish so I'm not really sure what benefit continuing this thread has. I think most of the stuff you're asking about is more or less documented and spelled out as openly as we're able to. What we're trying to do here is to make this stuff more open and available to people rather than locked away behind binary blobs. More or less everything we do is put into our wiki with very few exceptions. OpenMdev.io is made to be open to our community of folks working on Mediated Device/IO Virtualization functions on various projects so if you're a developer on this stuff and think anything is lacking you're welcome to contribute or or make suggestions in our IRC or Discord. I'm sure there's always room to improve and we put a ton of effort into trying to listen to feedback and improve upon things ourselves as well as accept contributions from others.