kvm libvirt: hostdev passthrough support 解决加密狗冲突问题
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 hostdevice enumeration support I'd offered a design for a few monthsback. As such I'd like to try and keep a consistent XML formatbetween the two. For reference the original mesage was here:http://www.redhat.com/archives/libvir-list/2008-April/msg00005.htmlThere were basically two ways to identify a device. Some devicesare '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 infodirectly associated with them. The reason for this is that one pieceof hardware may present many logical devices each with varying capabilities. As an example, a wifi card typically exports at least2 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 devicepassthrough. KVM and Xen both support passthrough of physicaldevices, either USB or PCI cards. OpenVZ supports passthroughof logical devices - in particular network interfaces.We need to allow for both possibilities in the domain XML forthis type of device. So, to expand on your proposal, I'd like to see the XML formathave a top level attribute indicating whether we're passing alogical or physical device, and then the capability name orbus name respectively. The child elements then need to providethe appropriate naming.USB has the further annoyance you identified that one couldconceivably do attachment based on USB bus address, or thevendor+product pair. The downside of former is that a busaddress changes every time you plug a device in. The downsideof the latter is that it is not neccessarily unique. We haveno choice but to allow both I'm afraid :-(Finally, with some systems we may have the option of specifyinga 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 specifyingthe 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. Moreto the point none of our underlying hypervisors use anythingother 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 actualdevice it chose, so we can fill in the <address> tag. NB Iknow QEMU doesn't allow this, but we need it in order todounplug 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 withI think we'll need something a little larger, along the linesof 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 anemacs whitespace rule setting.Modulo, the comments about the XML format, I think your patch is basicallysound & 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 :|