libpciaccess problem with new IO interface

[Adam Jackson]

On Sat, 2010-02-13 at 16:23 +1300, Michael Cree wrote:
> I have been trying out the new IO interface routines 
> (pci_device_open_io, etc.) in libpciaccess with a view that they might 
> solve the problem of MMIO on idiosyncratic architectures such as the old 
> Alphas.
> 
> In short, those routines do not work, at least not in the Linux sysfs 
> implementation.
> 
> In that implementation libpciaccess opens the sysfs PCI resource file as 
> a file then reads and writes (via pread and pwrite) are performed on the 
> resource file for IO byte, word and longword access.
> 
> The trouble with this implementation is that reading and writing the PCI 
> resource files in the Linux sysfs does not appear to be supported by the 
> kernel.  Only memory mapping the resource files is supported.

It depends on the architecture and the resource type.

On x86, for I/O resources, only read/write are supported.  mmap()
wouldn't work for at least two reasons.  One, there's nothing to mmap;
there's no place in memory address space where I/O ports live.  Two, if
you tried to fake it by mapping unbacked pages and interpreting the page
faults it generates, you'd need an x86 disassembler in the kernel to
figure out I/O direction/size/targets, since the fault itself doesn't
give you enough information (nor the size of the instruction to step
over).

On x86, for memory resources, only mmap() is currently supported.
read/write could be trivially supported - the syscall gives you all the
information you need - but oh my goodness would that ever be slow for
small operations.  Still, it'd work, and I can't come up with a good
reason _not_ to support it.  lkml is standing by ready to take your
call ;).

On arches with a relatively regular ISA (that is, not x86), you could
probably emulate mmap of memory resources on sparse memory machines with
the unbacked-page trick without being too disgusting, since decoding the
faulting instruction would be pretty straightforward.  It would probably
be even slower than dense memory, but if you don't have dense memory you
don't have many options.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20100215/d75030ba/attachment-0001.pgp