Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

pciback(4) [netbsd man page]

PCIBACK(4)						 BSD/xen Kernel Interfaces Manual						PCIBACK(4)

NAME
pciback -- Xen backend paravirtualized PCI pass-through driver SYNOPSIS
pciback* at pci? DESCRIPTION
The pciback driver is the backend part of the PCI pass-through functionality that can be used by the Xen dom0 to export pci(4) devices to a guest domain. To export a PCI device to a guest domain, the device has to be attached to pciback in the dom0. When the guest domain is NetBSD, the device attached to the pciback driver will attach to a xpci(4) bus inside the guest domain. EXAMPLES
To attach a device to the pciback driver, follow these steps: 1. look for the device PCI ID, via pcictl(8). 2. edit boot.cfg(5) and add the PCI ID to the list of PCI IDs that you want to attach to pciback, in bus:device.function notation. The list is passed to dom0 module via the pciback.hide parameter: pciback.hide=(bus:dev.fun)(bus:dev.func)(...) See also boot(8). 3. reboot dom0. 4. add the PCI ID to the list of PCI devices in the domain configuration file: pci = ['bus:dev.fun', '...'] 5. start the guest domain. SEE ALSO
pci(4), xpci(4), boot(8), pcictl(8) HISTORY
The pciback driver first appeared in NetBSD 5.1. AUTHORS
The pciback driver was written by Manuel Bouyer <bouyer@NetBSD.org>. CAVEATS
Currently, to attach a device to the pciback backend, this procedure has to be performed at boot(8) time. In the future, it will be possible to do it without requiring a dom0 reboot. SECURITY CONSIDERATIONS
As PCI passthrough offers the possibility for guest domains to send arbitrary PCI commands to a physical device, this has direct impact on the overall stability and security of the system. For example, in case of erroneous or malicious commands, the device could overwrite physi- cal memory portions, via DMA. BSD
January 8, 2011 BSD

Check Out this Related Man Page

PROTO(4)						   BSD Kernel Interfaces Manual 						  PROTO(4)

NAME
proto -- Driver for prototyping and H/W diagnostics SYNOPSIS
To compile this driver into the kernel, place the following line in your kernel configuration file: device proto Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5): proto_load="YES" DESCRIPTION
The proto device driver attaches to PCI devices when no other device drivers are present and creates device special files for all resources associated with the device. The driver itself has no knowledge of the device it attaches to. Programs can open these device special files and perform register-level reads and writes. As such, the proto device driver is nothing but a conduit or gateway between user space pro- grams and the hardware device. Examples for why this is useful include hardware diagnostics and prototyping. In both these use cases, it is far more convenient to develop and run the logic in user space. Especially hardware diagnostics requires a somewhat user-friendly interface and adequate reporting. Nei- ther is done easily as kernel code. FILES
All device special files corresponding to a PCI device are located under /dev/proto/pci<d>:<b>:<s>:<f> with pci<d>:<b>:<s>:<f> representing the location of the PCI device in the PCI hierarchy. A location includes: <d> The PCI domain number <b> The PCI bus number <s> The PCI slot or device number <f> The PCI function number Every PCI device has a device special file called pcicfg. This device special file gives access to the PCI configuration space. For each valid base address register (BAR), a device special file is created that contains the BAR offset and the resource type. A resource type can be either io or mem representing I/O port or memory mapped I/O space (resp.) EXAMPLES
A single function PCI device in domain 0, on bus 1, in slot 2 and having a single memory mapped I/O region will have the following device special files: /dev/proto/pci0:1:2:0/10.mem /dev/proto/pci0:1:2:0/pcicfg AUTHORS
The proto device driver and this manual page were written by Marcel Moolenaar <marcel@xcllnt.net>. SECURITY CONSIDERATIONS
Because programs have direct access to the hardware, the proto driver is inherently insecure. It is not advisable to use this driver on a production machine. MISSING FUNCTIONALITY
The proto driver does not yet support interrupts. Since interrupts cannot be handled by the driver itself, they must be converted into sig- nals and delivered to the program that has registered for interrupts. In order to test the transmission or reception of data, some means of doing direct memory access (DMA) by the device must be possible. This too must be under the control of the program. The details of how a program can set up and initiate DMA still need to be fleshed out. Support for non-PCI devices has not been implemented yet. BSD
April 29, 2014 BSD
Man Page