[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