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

On Fri, Jul 25, 2008 at 04:17:30PM -0400, Guido G?nther wrote: 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> Conceivably we could allow PCI devices by vendor+product, but I don't see much call for that since PCI device's don't (yet) appear/disappear on the fly & have a consistent address. More to the point none of our underlying hypervisors use anything other than the PCI address for PCI device passthrough. For USB, if we're doing attachment based on vendor+product, then libvirt needs to query QEMU to find out the actual device it chose, so we can fill in the <address> tag. NB I know QEMU doesn't allow this, but we need it in order todo unplug reliably, so we'll likely need to do it anyway. 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; }; Careful with indentation - check the HACKING file for an emacs whitespace rule setting. Modulo, the comments about the XML format, I think your patch is basically sound & following all our guidelines which is great :-) Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|