virtio是KVM環境下的I/O虛擬化的框架，目前已經使用到的虛擬化裝置包括block、net、scsi，本質是guest os與host os間的一種高效通訊機制。本文旨在對virtio通訊用到的eventfd進行分析。為了描述簡單，一般來說，稱guest側通知host側的行為為kick，host側通知guset側的行為為call。
參考資料：
1. virtio spec
2. Virtio 基本概念和裝置操作
3. note

1. 什麼是eventfd?

eventfd是隻存在於記憶體中的檔案，通過系統呼叫sys_eventfd可以建立新的檔案，它可以用於執行緒間、程序間的通訊，無論是核心態或使用者態。其實現機制並不複雜，參考核心原始碼樹的

 struct eventfd_ctx {
         struct kref kref;
         wait_queue_head_t wqh;
         /*
          * Every time that a write(2) is performed on an eventfd, the
          * value of the __u64 being written is added to "count" and a
          * wakeup is
 
 performed on "wqh". A read(2) will return the "count"
          * value to userspace, and will reset "count" to zero. The kernel
          * side eventfd_signal() also, adds to the "count" counter and
          * issue a wakeup.
          */
         __u64 count;
         unsigned int flags;
 };

eventfd的訊號實際上就是上面的count

virtio用到的eventfd其實是kvm中的ioeventfd機制，是對eventfd的又一層封裝（eventfd + iodevice）。該機制不進一步細說，下面結合virtio的kick操作使用來分析，包括兩部分：
1. 如何設定：如何協商該eventfd？
2. 如何產生kick訊號：是誰來負責寫從而產生kick訊號？

2. 如何設定？

即qemu使用者態程序是如何和kvm.ko來協商使用哪一個eventfd來kick通訊。
這裡就要用到kvm的一個系統呼叫：ioctl(KVM_IOEVENTFD, struct kvm_ioeventfd)，找一下qemu程式碼中執行該系統呼叫的路徑：

memory_region_transaction_commit() {
    address_space_update_ioeventfds() {
        address_space_add_del_ioeventfds() {
            MEMORY_LISTENER_CALL(eventfd_add, Reverse, &section,
            fd->match_data, fd->data, fd->e);
        }
    }
}

上面的eventfd_add有兩種可能的執行路徑：
1. mmio(Memory mapping I/O): kvm_mem_ioeventfd_add()
2. pio(Port I/O): kvm_io_ioeventfd_add()

通過程式碼靜態分析，上面的呼叫路徑其實只找到了一半，接下來使用gdb來檢視memory_region_transaction_commit()可能的執行路徑，結合vhost_blk（qemu使用者態新增的一項功能，跟qemu-virtio或dataplane在I/O鏈路上的層次類似）看一下設定eventfd的執行路徑:

#0  memory_region_transaction_commit () at /home/gavin4code/qemu-2-1-2/memory.c:799
#1  0x0000000000462475 in memory_region_add_eventfd (mr=0x1256068, addr=16, size=2, match_data=true, data=0, e=0x1253760)
    at /home/gavin4code/qemu-2-1-2/memory.c:1588
#2  0x00000000006d483e in virtio_pci_set_host_notifier_internal (proxy=0x1255820, n=0, assign=true, set_handler=false)
    at hw/virtio/virtio-pci.c:200
#3  0x00000000006d6361 in virtio_pci_set_host_notifier (d=0x1255820, n=0, assign=true) at hw/virtio/virtio-pci.c:884
#4  0x00000000004adb90 in vhost_dev_enable_notifiers (hdev=0x12e6b30, vdev=0x12561f8)
    at /home/gavin4code/qemu-2-1-2/hw/virtio/vhost.c:932
#5  0x00000000004764db in vhost_blk_start (vb=0x1256368) at /home/gavin4code/qemu-2-1-2/hw/block/vhost-blk.c:189
#6  0x00000000004740e5 in virtio_blk_handle_output (vdev=0x12561f8, vq=0x1253710)
    at /home/gavin4code/qemu-2-1-2/hw/block/virtio-blk.c:456
#7  0x00000000004a729e in virtio_queue_notify_vq (vq=0x1253710) at /home/gavin4code/qemu-2-1-2/hw/virtio/virtio.c:774
#8  0x00000000004a9196 in virtio_queue_host_notifier_read (n=0x1253760) at /home/gavin4code/qemu-2-1-2/hw/virtio/virtio.c:1265
#9  0x000000000073d23e in qemu_iohandler_poll (pollfds=0x119e4c0, ret=1) at iohandler.c:143
#10 0x000000000073ce41 in main_loop_wait (nonblocking=0) at main-loop.c:485
#11 0x000000000055524a in main_loop () at vl.c:2031
#12 0x000000000055c407 in main (argc=48, argv=0x7ffff99985c8, envp=0x7ffff9998750) at vl.c:4592

整體執行路徑還是很清晰的，vhost模組的vhost_dev_enable_notifiers()來告訴kvm需要用到的eventfd。

3. 如何產生kick訊號？

大體上來說，guest os覺得有必要通知host對virtqueue上的請求進行處理，就會執行vp_notify()，相當於執行一次port I/O（或者mmio），虛擬機器則會退出guest mode。這裡假設使用的是intel的vmx，當檢測到pio或者mmio會設定vmcs中的exit_reason，host核心態執行vmx_handle_eixt()，檢測exit_reason並執行相應的handler函式（kernel_io()），整體的執行路徑如下：

vmx_handle_eixt() {
    /* kvm_vmx_exit_handlers[exit_reason](vcpu); */
    handle_io() {
        kvm_emulate_pio() {
            kernel_io() {
                if (read) {
                    kvm_io_bus_read() {

                    }
                } else {
                    kvm_io_bus_write() {
                        ioeventfd_write();
                }
            }
        }
    }
}

最後會執行到ioeventfd_write()，這樣就產生了一次kick訊號。
如果該eventfd是由qemu側來監聽的，則會執行對應的qemu函式kvm_handle_io()；如果是vhost來監聽的，則直接在vhost核心模組執行vhost->handle_kick()。

qemu kmv_handle_io()的呼叫棧如下所示:

Breakpoint 1, virtio_ioport_write (opaque=0x1606400, addr=18, val=0) at hw/virtio/virtio-pci.c:270
270   {
(gdb) t
[Current thread is 4 (Thread 0x414e7940 (LWP 29695))]
(gdb) bt
#0  virtio_ioport_write (opaque=0x1606400, addr=18, val=0) at hw/virtio/virtio-pci.c:270
#1  0x00000000006d4218 in virtio_pci_config_write (opaque=0x1606400, addr=18, val=0, size=1) at hw/virtio/virtio-pci.c:435
#2  0x000000000045c716 in memory_region_write_accessor (mr=0x1606c48, addr=18, value=0x414e6da8, size=1, shift=0, mask=255) at /home/gavin4code/qemu/memory.c:444
#3  0x000000000045c856 in access_with_adjusted_size (addr=18, value=0x414e6da8, size=1, access_size_min=1, access_size_max=4, access=0x45c689 <memory_region_write_accessor>, mr=0x1606c48)
    at /home/gavin4code/qemu/memory.c:481
#4  0x000000000045f84f in memory_region_dispatch_write (mr=0x1606c48, addr=18, data=0, size=1) at /home/gavin4code/qemu/memory.c:1138
#5  0x00000000004630be in io_mem_write (mr=0x1606c48, addr=18, val=0, size=1) at /home/gavin4code/qemu/memory.c:1976
#6  0x000000000040f030 in address_space_rw (as=0xd05d00 <address_space_io>, addr=49170, buf=0x7f4994f6b000 "", len=1, is_write=true) at /home/gavin4code/qemu/exec.c:2114
#7  0x0000000000458f62 in kvm_handle_io (port=49170, data=0x7f4994f6b000, direction=1, size=1, count=1) at /home/gavin4code/qemu/kvm-all.c:1674
#8  0x00000000004594c6 in kvm_cpu_exec (cpu=0x157ec50) at /home/gavin4code/qemu/kvm-all.c:1811
#9  0x0000000000440364 in qemu_kvm_cpu_thread_fn (arg=0x157ec50) at /home/gavin4code/qemu/cpus.c:930
#10 0x0000003705e0677d in start_thread () from /lib64/libpthread.so.0
#11 0x00000037056d49ad in clone () from /lib64/libc.so.6
#12 0x0000000000000000 in ?? ()

至此，整個virtio的evenfd機制分析結束。