On Tue, Jul 29, 2008 at 11:53:46AM +0100, Daniel P. Berrange 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. Oh, one thing I meant to say. Contrary to my message in the thread above, and my previous reply, we should actually use 'subsys' or 'subsystem' instead of 'bus', to follow the HAL naming. > > 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"> eg <subsystem 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'> <hostdev mode='subsystem' type='usb'> > <source> > <product id='1155'/> > <vendor id='8214'/> > </source> > </hostdev> > > A USB device by address > > <hostdev mode='bus' bus='usb'> <hostdev mode='subsystem' type='usb'> > <source> > <address bus='003' dev='005'/> > </source> > </hostdev> > > A PCI device by address > > <hostdev mode='bus' bus='pci'> <hostdev mode='subsystem' type='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, > }; s/BUS/SUBSYS/ > > 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; s/bus/subsys/ > struct { > int type; /* enum virDomainHostdevCapabilityType */ > union { > struct { > char *name; > } net; > struct { > char *name; > } scsi; > }; > } cap; > } source; > char *target; > }; 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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list