Hi Johannes,
On 04.01.2018 09:05, Johannes Kliemann wrote:
thanks for that info. We also found memfd_create and came to the same conclusion that it won't work for our use case. Since there seems to be no way to constrain /dev/mem as we need we most probably will implement this functionality by ourselves on the kernel either through a kernel module or by adding a new custom syscall.
UIO solved this issue but also by creating a small custom kernel module for each driver what we wanted to prevent in the first place. Since we now need to change the kernel anyway we won't use UIO because the kernel also should become as small as possible at some point.
this is certainly the cleanest way.
As another principle idea - at least for handing out MMIO mappings for PCI resources, you may have a look at the pseudo files under /sys/devices. Here you can find all memory-mapped PCI resources as files, which could be mapped in user space via 'mmap'. E.g., the following command lists the available resources (with their file size corresponding to the information given by 'lspci -v'):
ls -l `find /sys/devices/pci0000:00 -name "resource*"`
However, this approach has some caveats:
* Core's IO_MEM service hands out resources based on their physical address. You would need to search /sys/devices for the matching PCI resource.
* A user-level device driver may request just a window of a PCI resource. So the dataspace handed out by core would need to carry the information about its offset from the beginning of the underlying file. We are somehow back at the start of the discussion. :-/
* It only works for the (arguably most prominent) case of PCI resources but not for other mappings. I am in particular thinking of the mapping of the PCI config space, which we will need to run the platform driver once the issue "RFC platform_drv/x86: Switch to ECAM/MMCONF" [1] is closed. I guess that we would need to have a Linux-specific platform driver then.
[1] https://github.com/genodelabs/genode/pull/2547
That said, in my opinion the tinkering with the files at /sys/ is not very attractive. If you are prepared to develop a generic kernel module for solving this problem at a lower level (and allowing us to reuse our existing platform driver on Linux), this should be the way to go.
Cherrs Norman