kvm libvirt: hostdev passthrough support 解决加密狗冲突问题

• From: "Daniel P. Berrange" <berrange redhat com>
• To: Guido Günther <agx sigxcpu org>
• Cc: libvir-list redhat com
• Subject: Re: [libvirt] [PATCH/RFC]: hostdev passthrough support
• Date: Tue, 29 Jul 2008 11:53:46 +0100

---

On Fri, Jul 25, 2008 at 04:17:30PM -0400, Guido G?nther wrote:

> Hi,

> attached is some basic support for host device passthrough. It enables

> you to passthrough usb devices in qemu/kvm via:

> 

> <devices>

>  <hostdev type='usb' vendor='0204' product='6025'/>

>  <hostdev type='usb' bus='001' device='007'/>

> </devices>



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.





> diff --git a/src/domain_conf.h b/src/domain_conf.h

> index b438bc8..1aa5c39 100644

> --- a/src/domain_conf.h

> +++ b/src/domain_conf.h

> @@ -257,7 +257,35 @@ struct _virDomainGraphicsDef {

>      } data;

>  };

>  

> +enum virDomainHostdevType {

> +    VIR_DOMAIN_HOSTDEV_TYPE_USB,

> +    VIR_DOMAIN_HOSTDEV_TYPE_PCI,

>  

> +    VIR_DOMAIN_HOSTDEV_TYPE_LAST

> +};

> +

> +typedef struct _virDomainHostdevDef virDomainHostdevDef;

> +typedef virDomainHostdevDef *virDomainHostdevDefPtr;

> +struct _virDomainHostdevDef {

> +    int type;

> +    union {

> +        struct {

> +            int byModel;

> +            union {

> +                unsigned vendor;

> +                unsigned bus;

> +            };

> +            union {

> +                unsigned product;

> +                unsigned device;

> +            };

> +        } usb;

> +        struct {

> +            /* TBD */

> +        } pci;

> +    };

> +    virDomainHostdevDefPtr next;

> +};



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;

    };





>  

>  /* Flags for the 'type' field in next struct */

>  enum virDomainDeviceType {

> @@ -265,6 +293,7 @@ enum virDomainDeviceType {

>      VIR_DOMAIN_DEVICE_NET,

>      VIR_DOMAIN_DEVICE_INPUT,

>      VIR_DOMAIN_DEVICE_SOUND,

> +    VIR_DOMAIN_DEVICE_HOST,

>  };

>  

>  typedef struct _virDomainDeviceDef virDomainDeviceDef;

> @@ -276,6 +305,7 @@ struct _virDomainDeviceDef {

>          virDomainNetDefPtr net;

>          virDomainInputDefPtr input;

>          virDomainSoundDefPtr sound;

> +	virDomainHostdevDefPtr hostdev;



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