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 :|