re: basic support for (software concept) "pci domains" in the MI pci code

[matthew green <mrg%eterna.com.au@localhost>]

   On Sun, Aug 23, 2009 at 01:17:05PM +1000, matthew green wrote:
   > to support modern Xorg and modern xen, we need a sane way to export the
   > concept of "pci domains" to userland.
   
   Can you please explain a bit more background here? The previous proprosals
   all were (at least to me) completely unclear about the what and why.

largely this is a software construct to appease other software
that we do not have time to rewrite.
   
   Isn't it enough to have a way for userland to tell which pciX is the parent
   of pciY and maybe a function to get the list of all pci$N that don't have a
   pci as parent?

sometimes they aren't parents but peers -- eg, psycho case.
there's an easy way to figure out which is bus A and bus B, but
they aren't parent/children in the autoconf sense.

MD code is the right place for this information to initially exposed.
   
   What is the "domain" value used for inside the kernel?

it is really only copied around, execpt that the drm code uses it
when constructing a "unique" name the card.  my understanding is
that xen wants to have a domain concept available for both
presenting a full topology to the userland as well as helping pci
passthru, but i do not really understand what the use there is.


ie, this is really useful for other software we don't control but
very much want to run.  i didn't see the point until xorg-server
and libpciaccess joined forced to make drm difficult (and there's
a lot more work we _have_ to do for drm future...)



.mrg.