Attached to the four e-mails that will follow this one are patches which will implement PCI Driver Domains. These patches *should* apply cleanly to xen-unstable changeset 8680:2add7a262530. A description of the contents of each patch will be included in the e-mails to follow. I have implemented PCI Driver Domains as a PCI Backend and PCI Frontend which communicate PCI configuration space requests via a shared page and event channel. Using the functionality added in changeset 8460, Xen can allow a domU to have direct access to physical I/O resources (i/o memory, i/o ports, interrupts). By allowing the domU to run the device driver for a particular device, we provide a more secure, isolated environment for that device driver to execute in (i.e. if it crashes, it should only take the domU with it, not Xen, dom0, or other domUs). PCI devices must be "hidden" from domain 0 at boot. To specify which devices, use the "pciback.hide" kernel command-line parameter (same syntax as Xen 2.0''s physdev_dom0_hide parameter except pass it to your Linux in domain 0 instead of Xen). PCI devices are subsequently seized by the backend (a regular PCI driver under Linux) during boot and owned by the pciback module (see /sys/bus/pci/driver/pciback/ for a list of devices it seized). Because the devices are not really hidden from domain 0 (they are seized before any other driver has a chance to attach to them), you can still view all of your devices in domain 0 using tools like lspci. Devices can be assigned to driver domains in the domain''s configuration file or on the command-line. The syntax for the command-line and the flat files should be backwards compatible with Xen 2.0 (see the included documentation for information on the new syntax and the SXP syntax). Xend detects the physical resources that a device requires and asks Xen to give the driver domain permission to them prior to the domain starting. Once the domain boots, the PCI frontend will interact with the PCI backend to share a single page and event channel and to determine where the PCI root buses are (which should be probed for devices by the guest). Driver domains address a large of security and stability concerns related to device drivers. Misbehaving (buggy) or malicious device drivers that would normally run at the same privilege level of the domain 0 kernel can be more isolated. While driver domains address a number of security concerns, a few remain and these should be considered prior to using this code. I''ve documented a few of them in the included documentation but the included list should not be considered exhaustive. I''ve tested this code on several classes of PCI devices (sound, network, serial ports) and on a couple different computers (all of the x86 variety) and found it to "work for me". I did not have access to a wide range of PCI devices or to different architectures for testing purposes. I''d be interested in hearing success/failure stories especially from those of you who have strange devices. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel