[Xen-devel] [PATCH][2/4] PCI Driver Domains: PCI Backend/Frontend

[Ryan <hap9@xxxxxxxxxxxxxx>]

This patch contains the PCI backend and frontend drivers for Linux
2.6.12. There are a couple of compile-time options in the backend and
frontend although the defaults should be sufficient to get you up and
running.

In the PCI backend, there are two modes of operation: pass-through and
virtual PCI bus. The virtual PCI bus mode renumbers the slot addresses
and places all of the exported devices on bus 0. For example, a device
at 06:01.0 will appear to the PCI frontend to be at 00:00.0 (a 2nd
exported device will show up at 00:01.0 and so on...). In pass-through
mode, no renumbering occurs. A device at 06:01.0 will appear at 06:01.0
to the PCI frontend (this is more similar to how things worked in Xen
2.0.x). In both modes, PCI bridges are not currently exported. While
virtual PCI bus mode can somewhat mask the real slot addresses to the
frontend (they're still visible in Xenstore at present), it may break
certain specialized devices and drivers which need to know the location
of other PCI devices (pass-through mode may be better suited for this
scenario).

There are two methods for the PCI frontend as well. The default method
integrates with the architecture-specific PCI code (in this case, i386).
This allows some PCI things that are architecture-specific to keep
working (like pci_mmap_page_range) that can't be handled by the
architecture-specific code in the backend. The other method is an
attempt at an architecture-independent driver that replaces the
architecture-specific PCI code in Linux with one that exclusively uses
Xen. It requires less patching to the architecture-specific code (I just
prevent it from compiling at all). While not tested on architectures
other than x86, it *should* enable easy porting of the PCI frontend to
ia64 and other architectures that Xen will support. I believe this
method also demonstrates that by leveraging the PCI backend, a driver
domain does not have to be concerned with as many architecture-specific
details regarding the PCI bus and devices. It's not yet clear to me
which method is best for the PCI frontend and I'd like to pick one or
the other so that there aren't two mutually-exclusive code paths to
maintain. Please let me know if you have problems with either method and
if you have any suggestions/comments on the merits of each approach.

If you have problems, there is a compile-time debug option that enables
some extra logging that may be useful in tracking down the problem.
There is also a run-time module parameter ("verbose_request") in the
frontend and backend that will output each configuration space request
that is sent/received across the shared page.

Signed-off-by: Ryan Wilson <hap9@xxxxxxxxxxxxxx>

pci-ddi.patch
Description: Text Data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel