On Wed, 25 Apr 2018 17:06:49 -0400 Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: > On Mon, Apr 09, 2018 at 12:35:10PM +0200, Gerd Hoffmann wrote: > > This little series adds three drivers, for demo-ing and testing vfio > > display interface code. There is one mdev device for each interface > > type (mdpy.ko for region and mbochs.ko for dmabuf). > > Perhaps a very basic question - but why do this in the kernel > as opposed to say outside the kernel - as a standalone process for example? Hi Konrad, The vfio mediated device interface allows sort of a software based SR-IOV model where an in-kernel driver can carve out a portion of its hardware to expose through the vfio interface and out to userspace, provided it can manage (mediate) device accesses securely. This is how our vGPU support works. So now we have host graphics drivers (i915 and nvidia) that know where the framebuffer of this vGPU lives and we want a way to expose that generically back to userspace, because QEMU doesn't know a vGPU from a NIC from a FC HBA. So we do that through the vfio API and we actually have two different interfaces for that, because reasons. The i915 driver implements one of those interfaces and nvidia the other, but of course you need an Intel graphics setup to test the former and you currently have to work for NVIDIA to test the latter and even when they release it you'd need high end hardware and licenses to be able to use it. So, Gerd was kind enough to implement these sample drivers so that we can test and develop both type of interfaces with no special hardware requirements. It's the same reason we have a sample mdev dummy PCI UART driver. A standalone process wouldn't really achieve the same goal. Thanks, Alex
