[Xen-devel] [PATCH][0/4] PCI Driver Domains

[Ryan <hap9@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel