Re: [libvirt] [PATCH/RFC]: hostdev passthrough support

This stuff is obviously going to have a correlation with the host device enumeration support I'd offered a design for a few months back. As such I'd like to try and keep a consistent XML format between the two. For reference the original mesage was here: http://www.redhat.com/archives/libvir-list/2008-April/msg00005.html There were basically two ways to identify a device. Some devices are 'physical' mapped straight to a piece of hardware (USB device, or PCI card) and would have '<bus>' element with hardware details.

eg a USB finger print reader appears as: <device> <name>usb_device_483_2016_noserial</name> <key>/org/freedesktop/Hal/devices/usb_device_483_2016_noserial</key> <parent>/org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_3</parent> <bus type="usb">

<vendor id="1155">SGS Thomson Microelectronics</vendor> <product id="8214">Fingerprint Reader</product> <address bus="003" dev="005"/> </bus> </device> Other devices are 'logical' devices, which don't have hardware info directly associated with them. The reason for this is that one piece of hardware may present many logical devices each with varying capabilities. As an example, a wifi card typically exports at least 2 network device - one control interface, and one for traffic. eg a wireless network interface for data traffic <device> <name>net_00_13_02_b9_f9_d3_0</name> <key>/org/freedesktop/Hal/devices/net_00_13_02_b9_f9_d3_0</key> <parent>/org/freedesktop/Hal/devices/pci_8086_4227</parent> <capability type="net"> <hwaddr>00:13:02:b9:f9:d3</hwaddr> <name>eth0</name> <capability type="80211"/> </capability> </device> In this case the unique device identifier is the '<name>' field but this case varying depending on the capability type. Different virt solutions have different capabilties for device passthrough. KVM and Xen both support passthrough of physical devices, either USB or PCI cards. OpenVZ supports passthrough of logical devices - in particular network interfaces. We need to allow for both possibilities in the domain XML for this type of device. So, to expand on your proposal, I'd like to see the XML format have a top level attribute indicating whether we're passing a logical or physical device, and then the capability name or bus name respectively. The child elements then need to provide the appropriate naming. USB has the further annoyance you identified that one could conceivably do attachment based on USB bus address, or the vendor+product pair. The downside of former is that a bus address changes every time you plug a device in. The downside of the latter is that it is not neccessarily unique. We have no choice but to allow both I'm afraid :-( Finally, with some systems we may have the option of specifying a target address - eg PCI device ID seen in guest. So, some examples.... A USB device by vendor+product <hostdev mode='bus' bus='usb'>

<source> <product id='1155'/> <vendor id='8214'/> </source> </hostdev> A USB device by address <hostdev mode='bus' bus='usb'>

<source> <address bus='003' dev='005'/> </source> </hostdev> A PCI device by address <hostdev mode='bus' bus='pci'>

<source> <address domain="0000" bus="00" slot="16" function="3"/> </source> </hostdev> A network card by name (ie for OpenVZ) <hostdev mode='capability'> <source name='eth0'/> </hostdev> A SCSI device by name (eg, SCSI PV passthrough), also specifying the target adress <hostdev mode='capability' type='scsi'> <source name='sg3'/> <target address='0:0:0:0'/> </hostdev>

Taking into account the various options we need to cope with I think we'll need something a little larger, along the lines of enum virDomainHostdevMode { VIR_DOMAIN_HSOTDEV_MODE_BUS, VIR_DOMAIN_HSOTDEV_MODE_CAPABILITY, }; enum virDomainHostdevBusType VIR_DOMAIN_HSOTDEV_BUS_TYPE_PCI, VIR_DOMAIN_HSOTDEV_BUS_TYPE_USB, };

enum virDomainHostdevCapabilityType { VIR_DOMAIN_HSOTDEV_CAP_TYPE_NET, VIR_DOMAIN_HSOTDEV_CAP_TYPE_SCSI, }; struct _virDomainHostdevDef { int mode; /* enum virDomainHostdevMode */ union { struct { int type; /* enum virDomainHostdevBusType */ union { struct { unsigned bus; unsigned device; unsigned vendor; unsigned product; } usb; struct { unsigned domain; unsigned bus; unsigned slot; unsigned function; } pci; } data; } bus;

struct { int type; /* enum virDomainHostdevCapabilityType */ union { struct { char *name; } net; struct { char *name; } scsi; }; } cap; } source; char *target; };