[libvirt] [PATCH/RFC]: hostdev passthrough support
Daniel P. Berrange
berrange at redhat.com
Tue Jul 29 11:04:00 UTC 2008
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 :|
More information about the libvir-list
mailing list