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

kvm libvirt: hostdev passthrough support 解决加密狗冲突问题的更多相关文章

  1. Eplan P8 2.7 加密狗 感叹号 解决方法

    Eplan安装完加密狗后一直感叹号异常,最近也是查了很多办法,最后发现是少了个驱动的原因. 就是上面这个驱动,这里放上驱动链接:https://lanzous.com/id5gi8f ,或者随便找一个 ...

  2. [转] XEN, KVM, Libvirt and IPTables

    http://cooker.techsnail.com/index.php/XEN,_KVM,_Libvirt_and_IPTables XEN, KVM, Libvirt and IPTables ...

  3. 编译驱动模块时,出现“stack protector enabled but no compiler support”[解决办法]【转】

    转自:http://blog.chinaunix.net/uid-26847859-id-3297170.html 原文地址:编译驱动模块时,出现“stack protector enabled bu ...

  4. Rockey 4加密狗介绍

    Rockey 4加密狗介绍 特点:该加密狗是单片机加密狗时代飞天公司的主力产品,R4一样继承了R2的硬件特征,具有全球唯一性硬件ID.R4内置了硬件随机数生成器,可以进行一些抗跟踪,或在硬件算法中参与 ...

  5. 老王教您怎么做cass7.1 8.0 9.1所有系列的复制狗 加密狗 破解狗

    cass7.1 8.0 9.1所有系列的复制狗 加密狗 破解狗本来是出于好奇看到网上有这样的东西,学了下感觉挺简单的,如果你是cass的初学者想仅仅是想学习这个软件,不想花大价格购买正版的,这个是可以 ...

  6. 磐石加密狗NT88管理层API

    磐石加密狗NT88管理层API   直接贴代码了 1 using System; 2 using System.Collections.Generic; 3 using System.Text; 4 ...

  7. 模拟美萍加密狗--Rockey2虚拟狗(五)

    虚拟狗开源后很多网友询问有关使用方法的问题,其实看我前四篇文章就应该了解怎样使用了,但还是写篇教程吧 [一].安装DSF (驱动模拟环境): 运行DSFx86Runtime.msi 如需改变安装目录请 ...

  8. 模拟美萍加密狗--Rockey2虚拟狗(二)

    按好了WDK,看了一天的DSF例子GenericHID,直接头大了,就能改个VID,PID让美萍识别成R2的狗.其他的什么各种描述符,根本无从下手,怪不得网上没有驱动模拟的加密狗,确实太复杂了,特别像 ...

  9. 模拟美萍加密狗--Rockey2虚拟狗(三)

    几经挣扎,我最终还是选择了虚拟设备的方法来模拟Rockey2加密狗.HID.DLL劫持+API劫持的办法技术上虽然简单些,但太繁琐了,不仅要转发大量的函数,还要Hook好几个API,向我这么懒的人可干 ...

随机推荐

  1. Elasticsearch 单模式下API的增删改查操作

    <pre name="code" class="html">Elasticsearch 单模式下API的增删改查操作 http://192.168. ...

  2. php 前台数据显示

    <pre name="code" class="html"> public function show(){ echo "访问了index ...

  3. 带你走进EJB--MDB

    在之前的文章中我们介绍了带你走进EJB--JMS 和 带你走进EJB--JMS编程模型 对JMS有了初步的了解, 作为EJB系列的文章我们会继续对EJB相关的内容做进一步深的学习和了解.而此次需要进行 ...

  4. Sumsets(完全背包)

    Sumsets Time Limit: 2000MS   Memory Limit: 200000K Total Submissions: 15045   Accepted: 5997 Descrip ...

  5. [置顶] c++播放Flash文件

    最近由于需要在程序中使用Flash播放,所以学习了下如何播放Flash,这里使用atl库中的CAxWindow来处理我们要播放的Flash!由于Flash的很多接口我们都不知道,所以可以参考前一篇文章 ...

  6. Ext JS学习第九天 Ext基础之 扩展原生的javascript对象

    此文来记录学习笔记: •Ext对于原生的javascript对象进行了一系列的扩展,我们把他们掌握好,更能深刻的体会Ext的架构,从而对我们的web开发更好的服务, 源码位置,我们可以从开发包的这个位 ...

  7. js超简单日历

    用原生js写了一个超级简单的日历.当做是练习js中的Date类型. 思路: 获取某个日期,根据年份计算出每个月的天数. 利用Date中的getDay()知道该月份的第一天为星期几. 循环创建表格,显示 ...

  8. linux驱动调试--段错误之oops信息分析

    linux驱动调试--段错误之oops信息分析 http://blog.chinaunix.net/xmlrpc.php?r=blog/article&uid=29401328&id= ...

  9. JavaSE学习总结第02天_Java基础语法1

      02.01 关键字的概述和使用 关键字概述:被Java语言赋予特定含义的单词 关键字特点:组成关键字的字母全部小写 关键字注意事项:goto和const作为保留字存在,目前并不使用,类似Notep ...

  10. HDU1004题解分析(字符串处理)

    这道题是从上个星期开始做的,看到题时觉得似曾相似,好像做过,理了一下思路敲完代码又不对,后来发现是数组用错了,之后又重新想了数组和比较用法,昨天改了一个多小时,后来样例输出全部正确,所有情况都考虑到了 ...