Re: [GSoC 2026] Userland PCI drivers

[Michael <macallan1888%gmail.com@localhost>]

Hello,

On Tue, 3 Mar 2026 18:48:36 -0300
Oliver Miyar Ugarte <olivermu%estudante.ufscar.br@localhost> wrote:

> I've been working on the Userland PCI Drivers project for GSoC 2026
> (https://wiki.netbsd.org/projects/project/userland_pci/) and have a
> draft implementation of the first milestone, achieved by mapping PCI
> BARs from userspace via a new ioctl.
> (https://github.com/NetBSD/src/pull/74)
> 
> This adds PCI_IOC_MAP_BAR to /dev/pci/pci_usrreq.c, allowing userspace
> to safely map device registers without using /dev/mem. I've tested it
> with QEMU's edu device and it returns the correct BAR offset and size.

You can already map PCI resources by their bus addresses via /dev/pci*,
and access config space via ioctl(PCI_IOC_BDF_CFG{READ|WRITE}).
That's what the Xserver uses.
See 
https://cvsweb.netbsd.org/bsdweb.cgi/xsrc/external/mit/libpciaccess/dist/src/netbsd_pci.c?rev=1.23
and https://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libpci/

What's missing is stuff like DMA and interrupts from userland.

No idea why the project proposal mentions /dev/mem at all - it's not
portable ( there's a lot of supported hardware where PCI bus addresses
do not map 1:1 to physical addresses in CPU space, and others where you
can only see actual RAM through /dev/mem, not PCI space ) and requires
knowledge of the underlying hardware other than the device you're
trying to talk to.

So, why the additional ioctl? You can already access config space, find
devices and their BARs, and mmap() them at offset == bus address
without any kernel changes.

have fun
Michael