背景

在鲲鹏云主机适配lava项目中，虚拟机内测试发现带lava盘(qemu与spdk存储后端通过vfio-user连接)做FIO测试，IOPS只有500，而物理机可以达到30w+，明显虚拟化哪里有问题。

关键词：
​鲲鹏​：ARMv8架构
​vfio-user​: qemu与spdk通过vfio-user协议连接

测试与现象

• 虚拟机内FIO测试命令

  fio -runtime=1200 -size=100% -bs=4k -rw=randwrite  -ramp_time=0 -iodepth=128 -numjobs=32 -direct=1 -ioengine=libaio -time_based -group_reporting -filename=/dev/nvme0n1 -name=4krandwrite -eta-newline=1
  

• 虚拟机内16个vcpu，15个vcpu处于跑满的状态，其中sys处理时间占10%，irq状态处理时间占90%, 一个vcpu有35%的时间处于user，14%处于sys，50%处于irq。 从host看，vcpu线程占用cpu很少，大概在10%左右。

• 使用perf查看虚拟机跑fio与不跑fio时的vmexit情况，看到跑fio的时候有更多的trap(data abort), 每秒大概千次级别。

判断与分析

iops只有500，一定是整个传输路径某个地方有瓶颈：从guest nvme driver准备好request，发通知给spdk，到spdk处理完request，通过中断通知guest。比较有可能出现问题的是前后端通知的路径上，可能因为某些原因走了慢路径。

先看前端通知后端的路径，我们希望前端guest内bar直接映射spdk设备内存，这样前端可以直接通知到后端。如果没有走这个路径的话qemu肯定会多做一些事，于是strace qemu进程，可以发现有很多的sendmsg调用，具体是VFIO_USER_REGION_WRITE这个调用。

查看vfio-user.rst对于这个msg描述

``VFIO_USER_REGION_WRITE``
--------------------------

If a device region is not mappable, it's not directly accessible by the client
via mmap() of the underlying fd. In this case, a client can write to a device
region with this message.

大概猜到可能是bar没有正常mmap，导致前端通知后端的路径增加。相同的代码在x86上是没问题的，在arm上为啥不能正常mmap了呢? 查看mmap这部分代码

vfio_region_mmap ->
    region->mmaps[i].mmap = mmap(NULL, region->mmaps[i].size, prot,
                                        MAP_SHARED, region->fd,
                                        region->fd_offset +
                                        region->mmaps[i].offset);

trace发现mmap失败的错误码是EINVAL，查看mmap的man page，和mmap的输入参数，看到mmap失败是最后一个参数offset没有页对其导致的。这里offset是4k，但是host pagesize是64k。

添加一个patch, 扩大mmap的范围，使offset为0，再移动mmap指针到需要的位置，问题得到解决。