[PATCH RFC]: Generic Linux multi-domain PCI handling

Benjamin Herrenschmidt benh at kernel.crashing.org
Thu Dec 29 15:59:59 PST 2005


On Tue, 2005-12-27 at 22:29 -0800, David S. Miller wrote:

> The final part of this change is to make linuxPciOpenFile() open
> domain'd files correctly.  Instead of "0000" we put the actual
> domain number there in the file path string, and we track the
> domain of the cached file descriptor so that still works correctly
> as well.
> 
> With this I have X11R7 CVS working on my sparc64 Radeon card, which
> sits on domain 1.
> 
> Comments?

Ah, good that finally somebody is having the guts of tackling this
issue :) I think there are other problems to be dealt with though (but I
haven't gone into details, just writing from the top of my mind_

 - PIO access (legacy and normal BAR-based). This is implemented with
hacks for platforms like ppc where an PIO is mapped somewhere in the CPU
physical memory space, with a single IO base. We actually need one per
domain. Same goes for legacy IO accesses which need to be per domain,
and thus the VGA arbitration probbaly needs domain knowledge..

 - Identification of PCI devices. I'm not sure what works and what not
here as I'n not familiar with that part of X, but what about things like
device IDs containing PCI bus:dev:fn in the config file and
identification of PCI device used between the server and the DRM ? I
suppose that syntax need to be augmented of the domain number

In general, also, I think we should try to generalise usage of mmap
of /proc and/or /sys instead of /dev/mem and isolate X from some of the
PCI details that it doesn't always get right. In fact, on linux, I think
X shoulnd't even try to do resource allocation on PCI...

BTW. I think David Airlie did some initial work on updating the PciTag
to hold domain numbers too...

Cheers,
Ben.





More information about the xorg mailing list