Hi! Author here! You can technically offload the transactions the real driver on your host does to wherever you want really. PCI is very delay-tolerant and it usually negotiates with the device so I see not much of an issue doing that proven that you can efficiently and performantly manage the throughput throughout the architecture. The thing that kinda makes PCIem special is that you are pretty much free to do whatever you want with the accesses the driver does, you have total freedom. I have made a simple NVME controller (With a 1GB drive I basically malloc'd) which pops up on the local PCI bus (And the regular Linux's nvme block driver attaches to it just fine). You can format it, mount it, create files, folders... it's kinda neat. I also have a simple dumb rasteriser that I made inside QEMU that I wanted to write a driver for, but since it doesn't exist, I used PCIem to help me redirect the driver writes to the QEMU instance hosting the card (Thus was able to run software-rendered DOOM, OpenGL 1.X-based Quake and Half-Life ports).

▲

yndoendo an hour ago | parent | next [-]

Just to hijack this thread on how resilient PCIe is. PS4 Linux hackers ran PCIe over UART serial connection to reverse engineer the GPU. [0] [1]

[0] https://www.psdevwiki.com/ps4/PCIe

[1] https://fail0verflow.com/blog/2016/console-hacking-2016-post...

▲

jacquesm 3 hours ago | parent | prev | next [-]

Fantastic tool, thank you for making this it is one of those things that you never knew you needed until someone took the time to put it together.

▲

gigatexal 3 hours ago | parent | prev [-]

This is really interesting. Could it be used to carve up a host GPU for use in a guest VM?

▲

cakehonolulu 3 hours ago | parent | next [-]

As in, getting the PCIem shim to show up on a VM (Like, passthrough)? If that's what you're asking for, then; it's something being explored currently. Main challenges come from the subsystem that has to "unbind" the device from the host and do the reconfiguration (IOMMU, interrupt routing... and whatnot). But from my initial gatherings, it doesn't look like an impossible task.

▲

fc417fc802 an hour ago | parent | prev [-]

> carve up

Passthru or time sharing? The latter is difficult because you need something to manage the timeslices and enforce process isolation. I'm no expert but I understand it to be somewhere between nontrivial and not realistic without GPU vendor cooperation.

Note that the GPU vendors all deliberately include this feature as part of their market segmentation.

	▲	benreesman 5 minutes ago \| parent [-]
		It would need to implement a few dozen ioctls, correctly stub the kernel module in guests, do a probably memory-safe assignment of GPU memory to guest, and then ultimately map that info to BAR/MSI-X semantics of a real kernel module. You could get VFIO pretty fast for a full start by correctly masking LTR bits, but to truly make it free you'd need a user space io_uring broker that had survived hundreds of millions of adversarial fuzz runs because there's only so fast the firmware blob can run even if it's preloaded into initramfs. Serious work, detail intense, but not so different in design to e.g. Carmack's Trinity engine. Doable.