Hmmm.... Wondering if this could be eventually used to emulate a PCIe card using another device, like a RaspberryPi or something more powerful... Thinking the idea of a card you could stick in a machine, anything from a 1x to 16x slot, that emulates a network card (you could run VPN or other stuff on the card and offload it from the host) or storage (running something with enough power to run ZFS and a few disks, and show to the host as a single disk, allowing ZFS on devices that would not support it). but this is probably not something easy...
by krupan
1 subcomments
So just to be clear, you have to boot up the physical machine with a kernel command-line argument to reserve some RAM for this to work? And the amount of RAM you reserve is for BAR memory? If you wanted multiple PCIem devices (can you do that?) you'd need to reserve RAM for each of them?
by Surac
2 subcomments
that is a huge win if you are developing drivers or even real hardware. it allows to iterate on protokols just with the press of a button
by
0 subcomment
by iamoutoftouch
1 subcomments
How is that better than emulating the device in QEMU or with something like libvfio-user (which also works on top of QEMU)?
by throwaway132448
5 subcomments
Tangential question: PCIe is a pretty future-proof technology to learn/invest in,
right? As in,
it is very unlikely to become obsolete in the next 5-10 years (like USB)?
by agent013
1 subcomments
I've been burned before by driver bugs that only manifested under very specific timing conditions or malformed responses from the device, tnx
by _lunix
1 subcomments
very interesting work! I've been exploring a different idea on the side, using SPDK+libvfio-user [0] to emulate PCIe devices inside QEMU, which doesn't require a kernel module but it's a bit less flexible than this approach.