设为首页 收藏本站
查看: 1906|回复: 0

[经验分享] virtio后端驱动详解

[复制链接]

尚未签到

发表于 2017-6-23 12:58:22 | 显示全部楼层 |阅读模式
  2016-10-08
  virtIO是一种半虚拟化驱动,广泛用于在XEN平台和KVM虚拟化平台,用于提高客户机IO的效率,事实证明,virtIO极大的提高了VM IO 效率,配备virtIO前后端驱动的情况下,客户机IO效率基本达到和宿主机一样的水平。咱们本次的分析以qemu-kvm架构的虚拟化平台为基础,分析virtIO前后端驱动。当然后端就指有qemu实现的虚拟PCI设备,而前端自然就是客户操作系统中的virtIO驱动。需要前后配合才能完成数据的传输。
  本节的重点在于首先对virtIO进行总体介绍,然后结合LInux 3.11.1内核代码对后端驱动进行分析。

  一、virtIO 总体介绍
  对于virtIO的基本介绍如前面所述,而virtIO的出现所解决的另一个问题就是给众多的虚拟化平台提供了一个统一的IO模型,KVM、XEN、VMWare等均可以利用virtIO进行IO虚拟化,在提高IO效率的同时也极大的减少了自家软件开发的工作量。那么对于virtIO基本介绍我们就不详细深入,事实上,前面已经足以说明virtIO是何方神圣,下面主要是深入内在分析virtIO 其实现原理。

  二、现有设备虚拟化存在的问题
  这里以网络驱动为例,其他的设备驱动类似。先看传统的利用简单虚拟网卡进行网络虚拟化的情况,这种情况下数据包的收发模式根物理机没有本质区别。虚拟网卡发现有数据包到来,需要先接收下来,这个过程会发生数据的复制,然后向客户机注入软件中断,客户机接收到信号,然后处理中断,最终完成数据包的处理。这种模式下工作效率的瓶颈主要两点:
  1、数据的复制
  2、根模式和非根模式的频繁切换
  即使目前qemu的虚拟网卡已经使用DMA的方式直接把数据写入到客户机内存,然后通知客户机,但是仍然免不了数据复制带来的性能开销。
  那么有没有一种方式能够彻底的解决上面两个问题呢??当然要彻底消除根模式和非根模式的切换是不可能的,毕竟虚拟机还是有Hypervisor管理的,但是我们可以最大程度的减少这种不必要的切换。virtIO为这一问题提供了比较好的解决方案。
  第一个问题:数据的复制
  在virtIO实现了零复制。不管是什么虚拟化平台,虚拟机是运行在host内存中或者说虚拟机共享同一块内存,那么既然如此我们就没有必要在同一块内存不同区域之间复制数据,而可以进行简单的地址重映射即可。以KVM虚拟机为例,虚拟机运行在HOST的内存中,且在HOST上表现为一个普通的qemu进程。前面我们分析qemu网络虚拟化的时候已经分析,宿主机接收到数据包会根据目的MAC进行数据包的转发,如果是发往客户机的,则把数据包转发到一个虚拟端口(tap设备模拟),其本质实际上只是把数据共享到一个用户空间应用程序(通过虚拟设备),这里我们就是指qemu,这个过程是不需要我们操心的。数据到了qemu,其实这里有一个Net client来接收,
  第二个问题:根模式和非根模式的频繁切换、
  这里考虑下为何会有线程或者说操作系统中用户模式和内核模式都是同样的道理,线程出现的很大一部分原因就是进程切换代价太高,需要保存和恢复的东西太多,以至于每次切换都要做很多重复的工作,这才有了线程或者说是轻量级的进程。那么在这里,根模式和非根模式也是这个道理,只是这个模式的切换比进程的切换需要消耗更多的资源,因为每次切换保存的不在是一个普通进程的上下文,而是一个虚拟机的上下文,尽管虚拟机在HOST上同样是表现为一个进程,但是其保存的资源更多。仍然以网络数据包的传送为例。传统的方式,物理网卡每接收到一个数据帧就需要中断CPU,让CPU处理调用相应的中断服务函数处理数据帧。那么虚拟网卡也是如此,HOST每转发一个数据包到客户机的虚拟网卡,在不使用DMA的情况下就一个数据帧触发一个软中断,客户机就必须VM-exit处理中断,然后VM-entry,该过程不仅包含了数据的复制还包含了根模式非根模式之间的频繁切换。而即使qemu采用DMA的方式把数据帧直接写入到客户机内存,然后通知客户机,同样免不了数据复制带来的开销。

  三、 virtIO的实现
  基于上面描述的问题,virtIo给出了比较好的而解决方案。 而事实上,virtIO的出现不仅仅是解决了效率的问题。其更是为各大虚拟化引擎提供了一个统一的外部设备驱动。
  我们先从存储的角度分析一个数据帧。首先一个数据帧可能会需要多个buffer块才能完成存储;而一个buffer在这里指我们调用函数申请的虚拟地址空间,对应到物理内存可能包含有多个物理内存块。
  qemu中用VirtQueueElement结构表示一个逻辑buffer,用VRingDesc结构描述一个物理内存块,用一个描述符数组集中管理所有的描述符。而前后端的配合通过两个ring来实现:VRingAvailVRingUsed。当HOST需要向客户机发送数据时,先从对应的virtqueue获取客户机设置好的buffer空间(实际的buffer空间由客户机添加到virtqueue),每次取出一个buffer,相关信息记录到VirtQueueElement结构中,然后对其进行地址映射,因为这里记录的buffer信息是客户机的物理地址,需要映射成HOST的虚拟地址才可以对其进行访问。每完成一个VirtQueueElement 即buffer的的写入,就需要记录VirtQueueElement相关信息到VRingUsed,并撤销地址映射。一个数据帧写入完成后会设置VRingUsed的idx字段并对客户机注入软件中断以通知客户机。
  数据帧的逻辑存储结构如下:
DSC0000.png

  而物理内存块由一个全局的描述符表统一管理,具体的管理如下图所示:
DSC0001.png

  后端驱动工作模式正是如此,下面我们还是深入分析下几个重要的数据结构:



struct VirtQueue
{
     VRing vring;//每个queue一个vring
     hwaddr pa;//记录virtqueue中关联的描述符表的地址
     /*last_avail_idx对应ring[]中的下标*/
     uint16_t last_avail_idx;//上次写入的最后一个avail_ring的索引,下次给客户机发送的时候需要从avail_ring+1
     /* Last used index value we have signalled on */
     uint16_t signalled_used;

     /* Last used index value we have signalled on */
     bool signalled_used_valid;

     /* Notification enabled? */
     bool notification;

     uint16_t queue_index;

     int inuse;

     uint16_t vector;
     void (*handle_output)(VirtIODevice *vdev, VirtQueue *vq);
     VirtIODevice *vdev;
     EventNotifier guest_notifier;
     EventNotifier host_notifier;
};
  VirtQueue是一个虚拟队列,之所以称之为队列是从其管理buffer的角度。HOST和客户机也正是通过VirtQueue来操作buffer。每个buffer包含一个VRing结构,对buffer的操作实际上是通过VRing来管理的。pa是描述符表的物理地址。last_avail_index对应VRingAvail中ring[]数组的下标,表示上次最后使用的一个buffer首个desc对应的ring[]中的下标。这里听起来有点乱,么关系,后面会详细解释。暂且先介绍这几个。



typedef struct VRing
{
     unsigned int num;//描述符表中表项的个数
     unsigned int align;
     hwaddr desc;//指向描述符表
     hwaddr avail;//指向VRingAvail结构
     hwaddr used;//指向VRingUsed结构
} VRing;
  前面说过,VRing管理buffer,其实事实上,VRing是通过描述符表管理buffer的。究竟是怎么个管理法?这里num表示描述符表中的表项数。align是对其粒度。desc表示描述符表的物理地址。avail是VRingAvail的物理地址,而used是VRingUsed的物理地址。到这里是不是有点清楚了捏??每一个描述符表项都对应一个物理块,参考下面的数据结构,每个表项都记录了其对应物理块的物理地址,长度,标志位,和next指针。同一buffer的不同物理块正是通过这个next指针连接起来的。现在应该比较清晰了吧!哈哈



typedef struct VRingDesc
{
     uint64_t addr;//buffer 的地址
     uint32_t len;//buffer的大小,需要注意当描述符作为节点连接一个描述符表时,描述符项的个数为len/sizeof(VRingDesc)
     uint16_t flags;
     uint16_t next;
} VRingDesc;



/*一个数据帧可能有多个VirtQueueElement,VirtQueueElement中的index */
typedef struct VirtQueueElement
{
     unsigned int index;
     unsigned int out_num;
     unsigned int in_num;
     /*in_addr和 out_addr保存的是客户机的物理地址,而in_sg和out_sg中的地址是host的虚拟地址,两者之间需要映射*/
     hwaddr in_addr[VIRTQUEUE_MAX_SIZE];
     hwaddr out_addr[VIRTQUEUE_MAX_SIZE];
     struct iovec in_sg[VIRTQUEUE_MAX_SIZE];
     struct iovec out_sg[VIRTQUEUE_MAX_SIZE];
} VirtQueueElement;
  再说这个VirtQueueElement,前面也说过其对应的是一个逻辑buffer块。而一个逻辑buffer块由多个物理内存块组成。index记录该逻辑buffer块的首个物理内存块对应的描述符在描述符表中的下标,out_num和in_num是指输出和输入块的数量。因为这里一个逻辑buffer可能包含可读区和可写区,即有些物理块是可读的而有些物理块是可写的,out_num记录可读块的数量,而in_num记录可写块的数量。in_addr是一个数组,记录的是可读块的物理地址,out_addr同理。但是由于物理地址是客户机的,所以要想在HOST访问,需要把这些地址映射成HOST的虚拟地址,下面两个就是保存的对应物理块在HOST的虚拟地址和长度。
  typedef struct VRingAvail



{
     uint16_t flags;//限制host是否向客户机注入中断
     uint16_t idx;
     uint16_t ring[0];//这是一个索引数组,对应在描述符表中表项的下标,代表一个buffer的head,即一个buffer有多个description组成,其head会记录到
                     //ring数组中,使用的时候需要从ring数组中取出一个head才可以
} VRingAvail;

typedef struct VRingUsedElem
{
     uint32_t id;
     uint32_t len;//应该表示它代表的数据段的长度
} VRingUsedElem;

typedef struct VRingUsed
{
     uint16_t flags;//用于限制客户机是否增加buffer后是否通知host
     uint16_t idx;//
     VRingUsedElem ring[0];//意义同VRingAvail
} VRingUsed;
  这三个放在一起说是因为这三个之间联系密切,而笔者也曾被这几个关系搞得晕头转向。先说VRingAvail和VRingUsed,两个字段基本一致,flags是标识位主要限制HOST和客户机的通知。VRing中的flags限制当HOST写入数据完成后是否向客户机注入中断,而VRingUsed中的flags限制当客户机增加buffer后,是否通知给HOST。这一点在高流量的情况下很有效。就像现在网络协议栈中的NAPI,为何采用中断加轮训而不是采用单纯的中断或者轮询。回到前面,二者也都有idx。VRingAvail中的idx表明客户机驱动下次添加buffer使用的ring下标,VRingUsed中的idx表明qemu下次添加VRingUsedElem使用的ring下标。
  然后两者都有一个数组,VRingAvail中的ring数组记录的是可用buffer 的head index.即
  if ring[0]=2
  then desctable[2] 记录的就是一个逻辑buffer的首个物理块的信息。
  virtqueue中的last_avail_idx记录ring[]数组中首个可用的buffer头部。即根据last_avail_idx查找ring[],根据ring[]数组得到desc表的下标。然后last_avail_idx++。
  每次HOST向客户机发送数据就需要从这里获取一个buffer head
  当HOST完成数据的写入,可能会产生多个VirtQueueElement,即使用多个逻辑buffer,每个VirtQueueElement的信息记录到VRingUsedVRingUsedElem数组中,一个元素对应一个VRingUsedElem结构,其中id记录对应bufferhead,len记录长度。
  小结:上面结合重要的数据结构分析了virtIO后端驱动的工作模式,虽然笔者尽可能的想要分析清楚,但是总感觉表达能力有限,不足之处还请谅解!下面会结合qemu源代码就具体的网络数据包的接收,做简要的分析。

  当然,开始还是从virtio_net_receive函数开始



static ssize_t virtio_net_receive(NetClientState *nc, const uint8_t *buf, size_t size)
{
     VirtIONet *n = qemu_get_nic_opaque(nc);
     VirtIONetQueue *q = virtio_net_get_subqueue(nc);
     VirtIODevice *vdev = VIRTIO_DEVICE(n);
     struct iovec mhdr_sg[VIRTQUEUE_MAX_SIZE];
     struct virtio_net_hdr_mrg_rxbuf mhdr;
     unsigned mhdr_cnt = 0;
     size_t offset, i, guest_offset;

     if (!virtio_net_can_receive(nc)) {
         return -1;
     }

     /* hdr_len refers to the header we supply to the guest */
     if (!virtio_net_has_buffers(q, size + n->guest_hdr_len - n->host_hdr_len)) {
         return 0;
     }

     if (!receive_filter(n, buf, size))
         return size;

     offset = i = 0;
     /*这里循环一次,就get到一个buffer*/
     while (offset < size) {
         VirtQueueElement elem;//一个elem表示一个buffer的数据
         int len, total;
         //sg作为一个指针,指向elem.in_sg,即sg=elem.in_sg。指向的是同一片内存区
         const struct iovec *sg = elem.in_sg;

         total = 0;
         //从virtqueue中取出所有的描述符信息,返回的是in_sg和out_sg的数量总和,如果为0表示这队列并没有实际的空间,无法装入数据
         if (virtqueue_pop(q->rx_vq, &elem) == 0) {
             if (i == 0)
                 return -1;
             error_report("virtio-net unexpected empty queue: "
                     "i %zd mergeable %d offset %zd, size %zd, "
                     "guest hdr len %zd, host hdr len %zd guest features 0x%x",
                     i, n->mergeable_rx_bufs, offset, size,
                     n->guest_hdr_len, n->host_hdr_len, vdev->guest_features);
             exit(1);
         }

         if (elem.in_num < 1) {
             error_report("virtio-net receive queue contains no in buffers");
             exit(1);
         }

         if (i == 0) {
             assert(offset == 0);
             if (n->mergeable_rx_bufs) {
                 mhdr_cnt = iov_copy(mhdr_sg, ARRAY_SIZE(mhdr_sg),
                                     sg, elem.in_num,
                                     offsetof(typeof(mhdr), num_buffers),
                                     sizeof(mhdr.num_buffers));
             }
             receive_header(n, sg, elem.in_num, buf, size);
             offset = n->host_hdr_len;
             total += n->guest_hdr_len;
             guest_offset = n->guest_hdr_len;
         } else {
             guest_offset = 0;
         }
         /* copy in packet.  ugh */
         /*进行数据的写入*/
         len = iov_from_buf(sg, elem.in_num, guest_offset,buf + offset, size - offset);
         /*total表示完成复制的数据*/
         total += len;
         /*offset表示下一刻要复制的数据到buffer头的偏移*/
         offset += len;
         /* If buffers can't be merged, at this point we
          * must have consumed the complete packet.
          * Otherwise, drop it. */
         if (!n->mergeable_rx_bufs && offset < size) {
#if 0
#endif
             return size;
         }

         /* signal other side i 代表第几个buffer*/
         /*到这里数据已经写入完成,需要撤销映射,更新ring的相关字段*/
         virtqueue_fill(q->rx_vq, &elem, total, i++);
     }

     if (mhdr_cnt) {
         stw_p(&mhdr.num_buffers, i);
         iov_from_buf(mhdr_sg, mhdr_cnt,
                      0,
                      &mhdr.num_buffers, sizeof mhdr.num_buffers);
     }
     /*i表示数据包使用了多少个逻辑buffer即elem*/
     virtqueue_flush(q->rx_vq, i);//这里会更新used_ring的idx,表明这些buffer 已经消费,可以回收
     virtio_notify(vdev, q->rx_vq);//通知客户机
     return size;
}
  参数想必不用过多解释,NetClientState代表当前网络接收端,buffer指向数据,size是数据的长度。前面的验证这里我们就暂且忽略了,重点从while循环开始,这里声明了一个局部变量VirtQueueElement用于从virt_queue中取元素,同时在循环体外边设置两个移动指针offset和i初始化成0.二者的意义后面自然明了,而循环体内部还有一个toal字段,我们最后一起说。往下看就调用了virtqueue_pop函数,该函数具体后面在分析,功能就是从队列中取出一个逻辑buffer,并记录相关信息到elem中。关于VirtQueueElement前面已经分析过;虾米那一个if是在开始写入数据之前,判断下是否支持合并buffer,是的话需要记录buffer的数量,并写入头部到buffer中(注意是最开始那个buffer块)。接着就要iov_from_buf函数往buffer块中写入数据了,每次按照一个逻辑buffer的大小进行写入直到写入数据结束。完成后调用virtqueue_fill函数,主要是撤销地址的映射并更新在VRingUsed中的ring[]映射,即获取一个VRingUsedElem,记录刚才完成写入的VirtQueueElement信息,主要是index和长度。就这样一直循环到写入数据结束。这样到最后就调用virtqueue_flushvirtio_notify函数更新VRingUsed中的idx并通知客户机。
  大致处理流程是这样的,细节方面,我们看先如何从一个virt_queue中取出元素的:



int virtqueue_pop(VirtQueue *vq, VirtQueueElement *elem)
{
     unsigned int i, head, max;
     hwaddr desc_pa = vq->vring.desc;

     if (!virtqueue_num_heads(vq, vq->last_avail_idx))
         return 0;

     /* When we start there are none of either input nor output. */
     elem->out_num = elem->in_num = 0;
     /*初始化成主描述表的表项数*/
     max = vq->vring.num;
     /*获取的是vringavail中的ring[avail]的值,对应描述符表中某个表项的下标*/
     i = head = virtqueue_get_head(vq, vq->last_avail_idx++);
     
     if (vq->vdev->guest_features & (1 << VIRTIO_RING_F_EVENT_IDX)) {
         vring_avail_event(vq, vring_avail_idx(vq));//设置了
         }
     //如果描述符项指向的是另一个描述符数组
     if (vring_desc_flags(desc_pa, i) & VRING_DESC_F_INDIRECT) {
         //描述符数组的大小应该是VRingDesc大小的整数倍
         if (vring_desc_len(desc_pa, i) % sizeof(VRingDesc)) {
             error_report("Invalid size for indirect buffer table");
             exit(1);
         }

         /* loop over the indirect descriptor table */
         max = vring_desc_len(desc_pa, i) / sizeof(VRingDesc);
         desc_pa = vring_desc_addr(desc_pa, i);//获取另一个描述符数组的地址
         i = 0;//从第一个描述符项开始
     }
     /* Collect all the descriptors */
     do {
         struct iovec *sg;
         //判断第i个描述符的属性
         if (vring_desc_flags(desc_pa, i) & VRING_DESC_F_WRITE) {
             if (elem->in_num >= ARRAY_SIZE(elem->in_sg)) {
                 error_report("Too many write descriptors in indirect table");
                 exit(1);
             }
             elem->in_addr[elem->in_num] = vring_desc_addr(desc_pa, i);
             /**/
             sg = &elem->in_sg[elem->in_num++];
         } else {
             if (elem->out_num >= ARRAY_SIZE(elem->out_sg)) {
                 error_report("Too many read descriptors in indirect table");
                 exit(1);
             }
             elem->out_addr[elem->out_num] = vring_desc_addr(desc_pa, i);
             sg = &elem->out_sg[elem->out_num++];
         }

         sg->iov_len = vring_desc_len(desc_pa, i);

         /* If we've got too many, that implies a descriptor loop. */
         if ((elem->in_num + elem->out_num) > max) {
             error_report("Looped descriptor");
             exit(1);
         }
     } while ((i = virtqueue_next_desc(desc_pa, i, max)) != max);

     /* Now map what we have collected */
     /*现在获取到了客户机设置的avail space,现在需要map到host内存,然后写入数据*/
     virtqueue_map_sg(elem->in_sg, elem->in_addr, elem->in_num, 1);
     virtqueue_map_sg(elem->out_sg, elem->out_addr, elem->out_num, 0);
     /*记录该数据段在整条数据帧中的索引*/
     elem->index = head;
     /*队列的使用元素加一*/
     vq->inuse++;

     trace_virtqueue_pop(vq, elem, elem->in_num, elem->out_num);
     return elem->in_num + elem->out_num;
}
  首先调用下函数virtqueue_num_heads检查下是否又可用的buffer head,然后初始化elem的out_numin_num为0,接着以 vq->last_avail_idx为索引从VRingAvailring数组中获取一个buffer head索引,并赋值给i和head。head要作为index写入到elem.index,i作为一个计数器记录一共多少物理buffer,即多少个desc。接着判断客户机是否支持VIRTIO_RING_F_EVENT_IDX,对于这个看一下官方的解释:



/* The Guest publishes the used index for which it expects an interrupt
  * at the end of the avail ring. Host should ignore the avail->flags field. */
/* The Host publishes the avail index for which it expects a kick
  * at the end of the used ring. Guest should ignore the used->flags field. */
#define VIRTIO_RING_F_EVENT_IDX        29
  简单点说,就是客户机希望HOST在使用完可用buffer后,中断虚拟机,忽略avail->flags ,同时HOST希望客户机使用完HOST添加的used buffer后,通知HOST,忽略 used->flags。
  然后判断刚才获取的head指向的desc是否是一个indirect,是的话表明该描述符项指向一个单独的描述符表,此描述符表单独构成一个buffer
  然后从下面的do循环开始,就要开始获取各个物理buffer信息了,这里分为两类:可读和可写。可写的物理buffer地址(客户机物理地址)记录到in_addr数组中;可读的记录到out_addr数组中;并记录in_numout_num;这样知道最后一个desc。获取完成后调用virtqueue_map_sg函数映射刚才我们获取到的各个物理buffer的地址,并记录到in_sgout_sg数组中,这样才可以在HOST访问到。
  这样经过virtqueue_pop函数,HOST已经获取了相应buffer的信息,下一步就是往buffer中写入数据 了。
  写入数据的过程就比较简单,这里就不赘述。那么写入数据完成后,调用的virtqueue_fill函数做了哪些工作呢?



void virtqueue_fill(VirtQueue *vq, const VirtQueueElement *elem,
                     unsigned int len, unsigned int idx)
{
     unsigned int offset;
     int i;

     trace_virtqueue_fill(vq, elem, len, idx);

     offset = 0;
     for (i = 0; i < elem->in_num; i++) {
         size_t size = MIN(len - offset, elem->in_sg.iov_len);

         cpu_physical_memory_unmap(elem->in_sg.iov_base,
                                   elem->in_sg.iov_len,
                                   1, size);

         offset += size;
     }

     for (i = 0; i < elem->out_num; i++)
         cpu_physical_memory_unmap(elem->out_sg.iov_base,
                                   elem->out_sg.iov_len,
                                   0, elem->out_sg.iov_len);
     /*idx表明这是第几个elem,一个elem代表一个buffer,而一个buffer会有一个description 的 head,这里idx对应head*/
     idx = (idx + vring_used_idx(vq)) % vq->vring.num;

     /* Get a pointer to the next entry in the used ring. */
     vring_used_ring_id(vq, idx, elem->index);
     vring_used_ring_len(vq, idx, len);
}
  因为前面已经将数据写入,所以就HOST而言已经不需要再次访问前面映射的地址,那么这里就需要撤销映射以便于下次映射另外的物理buffer,同时需要在
  VRingUsed的ring中添加元素映射我们使用过的elem,后面的vring_used_ring_idvring_used_ring_len就是完成这样的工作。这样,待整条数据写入完成(可能使用多个elem即多个逻辑buffer),在最后调用virtqueue_flush函数集体更新VRingUsed的idx,最后调用virtio_notify通知客户机!!

  virtIO和客户机Driver的通知机制:
  这些需要结合具体的PCI设备架构, 之前有分析过PCI设备地址映射,这里简要说下,PCI设备的寄存器通过其BAR空间映射到IO地址空间或者内存地址空间,映射范围记录在BAR中,virtIO 作为一个PCI设备有几个控制寄存器或者理解成控制区域,大致布局为:


  • Common configuration
  • Notifications
  • ISR Status
  • Device-specific configuration
  • PCI configuration access
  在qemu中也都定义了对应的宏与之匹配
  这里我们只关注ISR Status,它是一个32bit的寄存器,结构布局如下:
DSC0002.png

  当0位被设置的时候表明这是由virtQueue引起的中断
  当1位被设置的时候表明这是因为配置变化引起的中断
  在HOST完成数据写入,需要notify客户机时,调用前面提到的virtio_notify函数



void virtio_notify(VirtIODevice *vdev, VirtQueue *vq)
{
     if (!vring_notify(vdev, vq)) {
         return;
     }

     trace_virtio_notify(vdev, vq);
     vdev->isr |= 0x01;
     virtio_notify_vector(vdev, vq->vector);
}
  可以看到这里设置了0位为1,然后调用virtio_notify_vector函数,virtio_notify_vector其实就是简单的调用了virtio_pci_notify函数,virtio_pci_notify这里根据不同的类型,采用不同的方式向客户机注入中断,这里主要由MSI-x和普通注入两种方式。



static void virtio_pci_notify(DeviceState *d, uint16_t vector)
{
     VirtIOPCIProxy *proxy = to_virtio_pci_proxy_fast(d);

     if (msix_enabled(&proxy->pci_dev))
         msix_notify(&proxy->pci_dev, vector);
     else {
         VirtIODevice *vdev = virtio_bus_get_device(&proxy->bus);
         pci_set_irq(&proxy->pci_dev, vdev->isr & 1);
     }
}
  而客户机通知HOST就是想一个地址写入16位 的 queue index即可。比较关键的是Queue Notify Address的计算,这里我们下节介绍前端驱动的时候再讲!
  后记:
  由于笔者能力有限,文章中难免有错误或者不准确之处,若有老师发现,恳请指点!!谢谢!
  参考:
  1、virtiIO:Towards a De-Tacto Standard For Virtual I/O Devices
  2、Virtual I/O Device (VIRTIO) Version 1.0
  2、qemu1.7.1 源代码

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-387371-1-1.html 上篇帖子: HBase、Redis、MongoDB、Couchbase、LevelDB主流 NoSQL 数据库的对比 下篇帖子: Win7精简成功后的总结
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表