--- wikisrc/ports/xen/howto.mdwn 2014/12/26 23:36:34 1.51 +++ wikisrc/ports/xen/howto.mdwn 2014/12/26 23:46:22 1.52 @@ -750,78 +750,74 @@ See possibly outdated [Solaris domU instructions](/ports/xen/howto-solaris/). -Using PCI devices in guest domains ----------------------------------- +PCI passthrough: Using PCI devices in guest domains +--------------------------------------------------- -The domain0 can give other domains access to selected PCI devices. This -can allow, for example, a non-privileged domain to have access to a -physical network interface or disk controller. However, keep in mind -that giving a domain access to a PCI device most likely will give the -domain read/write access to the whole physical memory, as PCs don't have -an IOMMU to restrict memory access to DMA-capable device. Also, it's not -possible to export ISA devices to non-domain0 domains (which means that -the primary VGA adapter can't be exported. A guest domain trying to -access the VGA registers will panic). - -This functionality is only available in NetBSD-5.1 (and later) domain0 -and domU. If the domain0 is NetBSD, it has to be running Xen 3.1, as -support has not been ported to later versions at this time. - -For a PCI device to be exported to a domU, is has to be attached to the -`pciback` driver in domain0. Devices passed to the domain0 via the -pciback.hide boot parameter will attach to `pciback` instead of the -usual driver. The list of devices is specified as `(bus:dev.func)`, +The domain0 can give other domains access to selected PCI +devices. This can allow, for example, a non-privileged domain to have +access to a physical network interface or disk controller. However, +keep in mind that giving a domain access to a PCI device most likely +will give the domain read/write access to the whole physical memory, +as PCs don't have an IOMMU to restrict memory access to DMA-capable +device. Also, it's not possible to export ISA devices to non-domain0 +domains, which means that the primary VGA adapter can't be exported. +A guest domain trying to access the VGA registers will panic. + +If the domain0 is NetBSD, it has to be running Xen 3.1, as support has +not been ported to later versions at this time. + +For a PCI device to be exported to a domU, is has to be attached to +the "pciback" driver in dom0. Devices passed to the dom0 via the +pciback.hide boot parameter will attach to "pciback" instead of the +usual driver. The list of devices is specified as "(bus:dev.func)", where bus and dev are 2-digit hexadecimal numbers, and func a single-digit number: - pciback.hide=(00:0a.0)(00:06.0) + pciback.hide=(00:0a.0)(00:06.0) -pciback devices should show up in the domain0's boot messages, and the +pciback devices should show up in the dom0's boot messages, and the devices should be listed in the `/kern/xen/pci` directory. -PCI devices to be exported to a domU are listed in the `pci` array of -the domU's config file, with the format `'0000:bus:dev.func'` +PCI devices to be exported to a domU are listed in the "pci" array of +the domU's config file, with the format "0000:bus:dev.func". - pci = [ '0000:00:06.0', '0000:00:0a.0' ] + pci = [ '0000:00:06.0', '0000:00:0a.0' ] -In the domU an `xpci` device will show up, to which one or more pci -busses will attach. Then the PCI drivers will attach to PCI busses as -usual. Note that the default NetBSD DOMU kernels do not have `xpci` or -any PCI drivers built in by default; you have to build your own kernel -to use PCI devices in a domU. Here's a kernel config example: - - include "arch/i386/conf/XEN3_DOMU" - #include "arch/i386/conf/XENU" # in NetBSD 3.0 - - # Add support for PCI busses to the XEN3_DOMU kernel - xpci* at xenbus ? - pci* at xpci ? - - # Now add PCI and related devices to be used by this domain - # USB Controller and Devices - - # PCI USB controllers - uhci* at pci? dev ? function ? # Universal Host Controller (Intel) - - # USB bus support - usb* at uhci? - - # USB Hubs - uhub* at usb? - uhub* at uhub? port ? configuration ? interface ? - - # USB Mass Storage - umass* at uhub? port ? configuration ? interface ? - wd* at umass? - # SCSI controllers - ahc* at pci? dev ? function ? # Adaptec [23]94x, aic78x0 SCSI - - # SCSI bus support (for both ahc and umass) - scsibus* at scsi? - - # SCSI devices - sd* at scsibus? target ? lun ? # SCSI disk drives - cd* at scsibus? target ? lun ? # SCSI CD-ROM drives +In the domU an "xpci" device will show up, to which one or more pci +busses will attach. Then the PCI drivers will attach to PCI busses as +usual. Note that the default NetBSD DOMU kernels do not have "xpci" +or any PCI drivers built in by default; you have to build your own +kernel to use PCI devices in a domU. Here's a kernel config example; +note that only the "xpci" lines are unusual. + + include "arch/i386/conf/XEN3_DOMU" + + # Add support for PCI busses to the XEN3_DOMU kernel + xpci* at xenbus ? + pci* at xpci ? + + # PCI USB controllers + uhci* at pci? dev ? function ? # Universal Host Controller (Intel) + + # USB bus support + usb* at uhci? + + # USB Hubs + uhub* at usb? + uhub* at uhub? port ? configuration ? interface ? + + # USB Mass Storage + umass* at uhub? port ? configuration ? interface ? + wd* at umass? + # SCSI controllers + ahc* at pci? dev ? function ? # Adaptec [23]94x, aic78x0 SCSI + + # SCSI bus support (for both ahc and umass) + scsibus* at scsi? + + # SCSI devices + sd* at scsibus? target ? lun ? # SCSI disk drives + cd* at scsibus? target ? lun ? # SCSI CD-ROM drives NetBSD as a domU in a VPS @@ -832,10 +828,29 @@ hardware. This section explains how to virtual private server where you do not control or have access to the dom0. -TODO: Perhaps reference panix, prmgr, amazon as interesting examples. +VPS operators provide varying degrees of access and mechanisms for +configuration. The big issue is usually how one controls which kernel +is booted, because the kernel is nominally in the dom0 filesystem (to +which VPS users do not normally have acesss). + +A VPS user may want to compile a kernel for security updates, to run +npf, run IPsec, or any other reason why someone would want to change +their kernel. + +One approach is to have an adminstrative interface to upload a kernel, +or to select from a prepopulated list. + +Otehr approaches are pvgrub and py-grub, which are ways to start a +bootloader from the dom0 instead of the actual domU kernel, and for +that loader to then load a kernel from the domU filesystem. This is +closer to a regular physical computer, where someone who controls a +machine can replace the kernel. + +prmgr and pvgrub +---------------- -TODO: Somewhere, discuss pvgrub and py-grub to load the domU kernel -from the domU filesystem. +TODO: Perhaps reference panix, prmgr, amazon as interesting examples. +Explain what prmgr does. Using npf ---------