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

网中网

• From: "Daniel P. Berrange"
  
• To: Guido Günther
  
• 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:
>
>
>  
>  
>
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  '' element with hardware details.
eg a USB finger print reader appears as:

usb_device_483_2016_noserial
/org/freedesktop/Hal/devices/usb_device_483_2016_noserial
/org/freedesktop/Hal/devices/usb_device_0_0_0000_00_1d_3

SGS Thomson Microelectronics
Fingerprint Reader



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

net_00_13_02_b9_f9_d3_0
/org/freedesktop/Hal/devices/net_00_13_02_b9_f9_d3_0
/org/freedesktop/Hal/devices/pci_8086_4227

00:13:02:b9:f9:d3
eth0



In this case the unique device identifier is the '' 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






A USB device by address





A PCI device by address





A network card by name (ie for OpenVZ)



A SCSI device by name (eg, SCSI PV passthrough), also specifying
the target adress




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