qemu

1、官网

官网：http://wiki.qemu.org/Main_Page 官网：https://www.qemu.org/contribute/ 代码仓库：https://gitlab.com/qemu-project/qemu

15.7 MB Files 805.9 GB Storage 不能被这些数字迷惑，实际下载大小约为211.87 MiB（20210526） git clone https://gitlab.com/qemu-project/qemu.git

v5.0.0 Apr 29, 2020 v5.0.0-rc0 Mar 25, 2020 v2.5.1 Mar 30, 2016

基本上都是x.0.0~x.2.0版本命名方式

一次有趣的代码贡献：https://gitlab.com/qemu-project/qemu/-/issues/491

2、简介

VMWare Workstation 就是这样一个可以完美满足我要求的桌面用户最满意的虚拟机。我经常使用它来折腾各个 Linux 发行版，而且运行流畅。当然，在 Linux 这个开源的世界我们是不该去使用破解版这样的东西的。不过不用担心，在 Linux 江湖中，还有 VirtualBox、QEMU 这样的虚拟机软件可用。

QEMU 本身是一个非常强大的虚拟机，甚至在 Xen、KVM 这些虚拟机产品中都少不了 QEMU 的身影。在 QEMU 的官方文档中也提到，QEMU 可以利用 Xen、KVM 等技术来加速。为什么需要加速呢，那是因为如果单纯使用 QEMU 的时候，它自己模拟出了一个完整的个人电脑，它里面的 CPU 啊什么的都是模拟出来的，它甚至可以模拟不同架构的 CPU，比如说在使用 Intel X86 的 CPU 的电脑中模拟出一个 ARM 的电脑或 MIPS 的电脑，这样模拟出的 CPU 的运行速度肯定赶不上物理 CPU。使用加速以后呢，可以把客户操作系统的 CPU 指令直接转发到物理 CPU，自然运行效率大增。

QEMU 同时也是一个非常简单的虚拟机，给它一个硬盘镜像就可以启动一个虚拟机，如果想定制这个虚拟机的配置，比如用什么样的 CPU 啊、什么样的显卡啊、什么样的网络配置啊，指定相应的命令行参数就可以了。它支持许多格式的磁盘镜像，包括 VirtualBox 创建的磁盘镜像文件。它同时也提供一个创建和管理磁盘镜像的工具 qemu-img。QEMU 及其工具所使用的命令行参数，直接查看其文档即可。

Intel Core i7-4770K 的 CPU，虚拟出的 XP 也分配了 2G 的内存和两个 CPU，但是流畅度仍较差。说明单纯使用 QEMU 还是不能满足我们桌面用户的需要。配合Xen 或者 KVM 呢？性能是否会有质的飞跃？

QEMU 是一个强大的虚拟机软件，它可以完全以软件的形式模拟出一台完整的电脑所需的所有硬件，甚至是模拟出不同架构的硬件，在这些虚拟的硬件之上，可以安装完整的操作系统。强烈推荐这篇文章：https://www.cnblogs.com/sunylat/p/6217536.html

为了提高虚拟机软件的性能，开发者们各显神通。其中，最常用的办法就是在主操作系统中通过内核模块开一个洞，通过这个洞将虚拟机中的操作直接映射到物理硬件上，从而提高虚拟机中运行的操作系统的性能。

在社区中，大家常把 KVM 和 Xen 相提并论，但是它们其实完全不一样。从上图可以看出，使用内核模块加速这种模式，主操作系统仍然占主导地位，内核模块只是在主操作系统中开一个洞，用来连接虚拟机和物理硬件，给虚拟机加速，但是虚拟机中的客户操作系统仍然受到很大的限制。这种模式比较适合桌面用户使用，主操作系统仍然是他们的主战场，不管是办公还是打游戏，都通过主操作系统完成，客户操作系统只是按需使用。至于 Xen，则完全使用不同的理念，比较适合企业级用户使用，桌面用户就不要轻易去碰了。

guest----host

DKMS简介我们都知道，如果要使用没有集成到内核之中的Linux驱动程序需要手动编译。当然，这并不是一件什么难事，即使是对于没有编程经验的Linux使用者，只要稍微有点hacker的意识，努力看看代码包里的Readme或者INSTALL文件，按部就班的执行几条命令还是很容易办到的。但这里还有一个问题，Linux模块和内核是有依赖关系的，如果遇到因为发行版更新造成的内核版本的变动，之前编译的模块是无法继续使用的，我们只能手动再编译一遍。这样重复的操作有些繁琐且是反生产力的，而对于没有内核编程经验的使用者来说可能会造成一些困扰，使用者搞不清楚为什么更新系统之后，原来用的好好的驱动程序突然就不能用了。这里，就是Dell创建的DKMS项目的意义所在。DKMS全称是Dynamic Kernel Module Support，它可以帮我们维护内核外的这些驱动程序，在内核版本变动之后可以自动重新生成新的模块。

KVM 和 QEMU 是相辅相成的，QEMU 可以使用 KVM 内核模块加速，而 KVM 需要使用 QEMU 运行虚拟机。从上图可以看到，如果要使用 Ubuntu 的包管理软件安装 KVM，其实安装的就是 qemu-kvm。而 qemu-kvm 并不是一个什么很复杂的软件包，它只包含很少量几个文件，如下图：用 man 命令查看一下它的文档，发现 qemu-kvm 包不仅包含的文件很少，而且它的可执行文件 kvm 也只是对 qemu-system-x86_64 命令的一个简单包装

可以这么说，如果没有 VirtualBox 的话，QEMU+KVM 的组合应该是桌面用户的首选。下一篇我将尝试 VirtualBox，VirtualBox 号称是最强大的开源虚拟机系统。

第三方虚拟机管理工具 virt-manager

而且 VirtualBox 并不仅仅适用于桌面用户，对于企业级的应用，它也是可以的。

dpkg -L 命令 Xen 具有非常高的难度，别说玩转，就算仅仅只是理解它，都不是那么容易。

在 Xen 中，则根本没有 Host System 的概念，传说它所有的虚拟机都直接运行于硬件之上，虚拟机运行的效率非常的高，虚拟机之间的隔离性非常的好。

当然，传说只是传说。我刚开始也是很纳闷，怎么可能让所有的虚拟机都直接运行于硬件之上。后来我终于知道，这只是一个噱头。虚拟机和硬件之间，还是有一个管理层的，那就是 Xen Hypervisor。当然 Xen Hypervisor 的功能毕竟是有限的，怎么样它也比不上一个操作系统，因此，在 Xen Hypervisor 上运行的虚拟机中，有一个虚拟机是具有特权的，它称之为 Domain 0，而其它的虚拟机都称之为 Domain U。

既然 Domain 0 也是一个虚拟机，也是被管理的对象，所以可以给它分配很少的资源，然后将其余的资源公平地分配到其它的 Domain。但是很奇怪的是，所有的虚拟机管理软件其实都是运行在这个 Domain 0 中的。同时，如果要连接到其它 Guest System 的控制台，而又不是使用远程桌面（VNC）的话，这些控制台也是显示在 Domian 0 中的。所以说，这是一个奇异的架构，是一个让人很不容易理解的架构。

这种架构桌面用户不喜欢，因为 Host System 变成了 Domain 0，本来应该掌控所有资源的主操作系统变成了一个受管理的虚拟机，本来用来打游戏、编程、聊天的主战场受到限制了，可能不能完全发挥硬件的性能了，还有可能运行不稳定了，自然会心里不爽。（Domain 0确实不能安装专用显卡驱动，确实会运行不稳定，这个后面会讲。）但是企业级用户喜欢，因为所有的 Domain 都是虚拟机，所以可以更加公平地分配资源，而且由于 Domain U 不再是运行于 Domian 0 里面的软件，而是和 Domain 0 平级的系统，这样即使 Domain 0 崩溃了，也不会影响到正在运行的 Domain U。（真的不会有丝毫影响吗？我表示怀疑。）

1.Xen 虚拟机不应该是桌面用户的首选，因为它架构比较奇异不容易理解，可能因内核升级而出现不稳定，不能充分发挥桌面硬件的性能，比如显卡；桌面用户还是应该首选 VirtualBox。

2.企业及客户可以考虑 Xen，因为它可以提供较好的性能和隔离性，企业级用户不需要桌面用户那么多的功能，所以可以把 Domain 0 做到很薄，可以完全不要图形界面，也不用经常升级内核，甚至可以选择一个经过修改优化的内核，这样就可以在一套硬件上运行尽可能多的虚拟机。

3、在qemu中模拟设备

https://zhuanlan.zhihu.com/p/57526565

MemoryRegion 存储区域

硬件模拟无外乎两个东西，一个是中断，一个是IO访问。

中断很简单，知道中断号，用qemu_set_irq()或者qemu_irq_pluse()往里种就可以了。

MemoryRegion：这表示一组面向Guest的，具有相同属性的内存区。后面简称MR。系统有全局的总MR，你直接用get_system_memory()就可以拿到了。所以你实际上任何时候都可以访问全局任何内存。

MemoryRegionCache：这表示一片为了满足Guest需要的一片临时的“真内存”。换句话说，MemoryRegion是描述一片内存区，MemoryRegionCache是真的要用的内存，Hypervisor根据需要动态申请，后面简称MRC。如果你不是要深入定制，一般你不管这个东西没有任何问题。

AddressSpace：这表示一个地址空间，一个地址空间可以包含多个不同属性的MR。后面简称AS。AS是和MR直接对应的，所以你可以直接用address_space_memory拿到对应get_system_memory()的AS。

FlatView：这表示看到的地址空间。这就比较绕了。这么说：AS是立体的，里面的MR是相互独立的，他们可以交叠，转义，动态开关等。但当你去访问的时候，某个时刻，某个物理地址总是对应着某个MR中的地址，FlatView用来表示层叠的结果。后面这个简称FV。FV大部分时候写设备模拟的时候都不用管，它是用于深入处理Host这边访问内存的时候用的，比如通过address_space_to_flatview(as)把as换成fv，然后用flatview_read/write()进行本地内存访问。

memory_region_init_io(&iomr, owner, ops, priv, name, size);

4、理解qemu中的xhci实现

qemu/hw/usb/hcd-xhci.c ->static void usb_xhci_realize(struct PCIDevice *dev, Error **errp)

api文档：https://qemu.readthedocs.io/en/latest/devel/memory.html

void memory_region_init_io(MemoryRegion *mr, Object *owner, const MemoryRegionOps *ops, void *opaque, const char *name, uint64_t size)

Initialize an I/O memory region.

Description

Accesses into the region will cause the callbacks in ops to be called. if size is nonzero, subregions will be clipped to size.

void memory_region_init_io(MemoryRegion *mr,
                           Object *owner,
                           const MemoryRegionOps *ops,
                           void *opaque,
                           const char *name,
                           uint64_t size)
{
    memory_region_init(mr, owner, name, size);
    mr->ops = ops ? ops : &unassigned_mem_ops;
    mr->opaque = opaque;
    mr->terminates = true;
}

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

void memory_region_add_subregion(MemoryRegion *mr, hwaddr offset, MemoryRegion *subregion)

Add a subregion to a container.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>

void memory_region_init(MemoryRegion *mr, Object *owner, const char *name, uint64_t size)

Initialize a memory region

qemu中：

#define MAXSLOTS 64
#define LEN_DOORBELL    ((MAXSLOTS + 1) * 0x20)

static const MemoryRegionOps xhci_doorbell_ops = {
    .read = xhci_doorbell_read,
    .write = xhci_doorbell_write,
    .valid.min_access_size = 4,
    .valid.max_access_size = 4,
    .endianness = DEVICE_LITTLE_ENDIAN,
};

memory_region_init_io(&xhci->mem_doorbell, OBJECT(xhci), &xhci_doorbell_ops, xhci,
                          "doorbell", LEN_DOORBELL);

可以看出LEN_DOORBELL不为0

#define OFF_DOORBELL    0x2000
memory_region_add_subregion(&xhci->mem, OFF_DOORBELL, &xhci->mem_doorbell);

后面就太多了，发现这样也并没有什么意义。

memory_region_dispatch_write

memory_region_write_accessor

mr->ops->write(mr->opaque, addr, tmp, size);

[root@chroot <vtcompile> ~/buildenv/Trunk/source/app/qemu/qemu-2.5.1 ]#grep -R memory_region_dispatch_write
exec.c:                    result |= memory_region_dispatch_write(mr, addr1, val, 8,
exec.c:                    result |= memory_region_dispatch_write(mr, addr1, val, 4,
exec.c:                    result |= memory_region_dispatch_write(mr, addr1, val, 2,
exec.c:                    result |= memory_region_dispatch_write(mr, addr1, val, 1,
exec.c:        r = memory_region_dispatch_write(mr, addr1, val, 4, attrs);
exec.c:        r = memory_region_dispatch_write(mr, addr1, val, 4, attrs);
exec.c:        r = memory_region_dispatch_write(mr, addr1, val, 2, attrs);
memory.c:MemTxResult memory_region_dispatch_write(MemoryRegion *mr,
hw/s390x/s390-pci-inst.c:        memory_region_dispatch_write(mr, offset, data, len,
hw/s390x/s390-pci-inst.c:        memory_region_dispatch_write(mr, env->regs[r3] + i * 8,
hw/vfio/pci-quirks.c.bak:                memory_region_dispatch_write(&vdev->pdev.msix_table_mmio,
hw/vfio/pci-quirks.c:                memory_region_dispatch_write(&vdev->pdev.msix_table_mmio,
Binary file x86_64-softmmu/qemu-system-x86_64 matches
Binary file x86_64-softmmu/memory.o matches
Binary file x86_64-softmmu/hw/vfio/pci-quirks.o matches
Binary file x86_64-softmmu/exec.o matches
Binary file x86_64-softmmu/cputlb.o matches
Binary file root@10.70.22.175 matches
include/exec/memory.h: * memory_region_dispatch_write: perform a write directly to the specified
include/exec/memory.h:MemTxResult memory_region_dispatch_write(MemoryRegion *mr,
softmmu_template.h:    memory_region_dispatch_write(mr, physaddr, val, 1 << SHIFT,

5、追踪CR_STOP_ENDPOINT命令

gdb调试打印全部堆栈：

pidof kvm
gdb qemu-system-x86_64 -p 1234
b memory_region_dispatch_write(不推荐太多)
b xhci_process_commands
handle SIGPIPE nostop(必须要有这个，不然c后就断了)
c

(gdb) bt
#0  xhci_process_commands (xhci=0x5600a5a6e000) at hw/usb/hcd-xhci.c:2690
#1  0x000056009ea71881 in memory_region_write_accessor (mr=<optimized out>, addr=<optimized out>, value=<optimized out>, size=<optimized out>, shift=<optimized out>,
    mask=<optimized out>, attrs=...) at /home/vtcompile/buildenv/Trunk/source/app/qemu/qemu-2.5.1/memory.c:451
#2  0x000056009ea719cb in access_with_adjusted_size (addr=addr@entry=0, value=value@entry=0x7f656bbea958, size=size@entry=4, access_size_min=<optimized out>,
    access_size_max=<optimized out>, access=access@entry=0x56009ea71850 <memory_region_write_accessor>, mr=mr@entry=0x5600a5a6ed50, attrs=attrs@entry=...)
    at /home/vtcompile/buildenv/Trunk/source/app/qemu/qemu-2.5.1/memory.c:507
#3  0x000056009ea73400 in memory_region_dispatch_write (mr=mr@entry=0x5600a5a6ed50, addr=0, data=0, size=size@entry=4, attrs=attrs@entry=...)
    at /home/vtcompile/buildenv/Trunk/source/app/qemu/qemu-2.5.1/memory.c:1159
#4  0x000056009ea2cb5e in address_space_rw (as=0x56009f421c80, addr=4227948544, attrs=..., buf=buf@entry=0x7f6580d6e028 "", len=4, is_write=true)
    at /home/vtcompile/buildenv/Trunk/source/app/qemu/qemu-2.5.1/exec.c:2551
#5  0x000056009ea704b8 in kvm_cpu_exec (cpu=cpu@entry=0x5600a3a48000) at /home/vtcompile/buildenv/Trunk/source/app/qemu/qemu-2.5.1/kvm-all.c:3123
#6  0x000056009ea57344 in qemu_kvm_cpu_thread_fn (arg=0x5600a3a48000) at /home/vtcompile/buildenv/Trunk/source/app/qemu/qemu-2.5.1/cpus.c:1066
#7  0x00007f657a2d6b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#8  0x00007f657a020a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#9  0x0000000000000000 in ?? ()

6、根据google查找原因

google：xhci: FIXME: endpoint stopped w/ xfers running, data might be lost

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=980833

passthrough：透传;通过;直通;穿过;经过 stick：枝条;枯枝;柴火棍儿;球棍;条状物;棍状物

他使用了一个金士顿2.0的U盘（0951:1642 Kingston Technology DT101 G2）挂载到xhci主控，然后将U盘分区格式化成ext4文件系统。

fdisk -l
设备       启动  起点     末尾     扇区  大小 Id 类型
/dev/sda1  *     2048 61439999 61437952 29.3G  7 HPFS/NTFS/exFAT


设备       启动  起点     末尾     扇区  大小 Id 类型
/dev/sda1  *     2048 61439999 61437952 29.3G  7 HPFS/NTFS/exFAT
root@ubuntu180001:~# mkfs.ext4 /dev/sda1
mke2fs 1.44.1 (24-Mar-2018)
/dev/sda1 有一个 ntfs 文件系统
Proceed anyway? (y,N) y
/dev/sda1 已经挂载； 取消建立 文件系统 ！
root@ubuntu180001:~# umount !$
umount /dev/sda1
root@ubuntu180001:~# mkfs.ext4 /dev/sda1
mke2fs 1.44.1 (24-Mar-2018)
/dev/sda1 有一个 ntfs 文件系统
Proceed anyway? (y,N) y
创建含有 7679744 个块（每块 4k）和 1921360 个inode的文件系统
文件系统UUID：a1a426ab-d82b-4dca-88e8-f3590bd056ce
超级块的备份存储于下列块：
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000

正在分配组表： 完成
正在写入inode表： 完成
创建日志（32768 个块） 完成
写入超级块和文件系统账户统计信息： 已完成

然鹅并没有复现问题。

os-posix:273 kvm: -device nec-usb-xhci,id=xhci,bus=pci.0,addr=0x1b.0x0: 'nec-usb-xhci' is not a valid device model name

发现是qemu文件被重定向了，即qemu文件中没有放开xhci主控端口数量。

ovirt几种网卡（e1000, rtl8139, virtio）的简要说明

ovirt创建网卡时候有3种选择，分别是e1000, rtl8139, virtio。

“rtl8139”这个网卡模式是qemu-kvm默认的模拟网卡类型，RTL8139是Realtek半导体公司的一个10/100M网卡系列，是曾经非常流行（当然现在看来有点古老）且兼容性好的网卡，几乎所有的现代操作系统都对RTL8139网卡驱动的提供支持。 “e1000”系列提供Intel e1000系列的网卡模拟，纯的QEMU（非qemu-kvm）默认就是提供Intel e1000系列的虚拟网卡。 “virtio” 类型是qemu-kvm对半虚拟化IO（virtio）驱动的支持。 virtio网卡数据交换性能大幅度领先平台上的e1000网卡和rtl8139网卡，一般情况下都建议使用virtio网卡。e1000网卡虽然性能比较差，但是兼容性比较好，有时候需要定位问题就要将网卡切换成e1000。

这三个网卡的最大区别(此处指最需要关注的地方)是速度： rtl8139 10/100Mb/s e1000 1Gb/s virtio 10Gb/s

注意virtio是唯一可以达到10Gb/s的，根据文献一，其iperf测试速率可达到9.4。文献1还提到如果virtio配置不合理速度只能达到3.6。不用担心这个情况，经查验ovirt自己生成的虚拟机配置都是合理的。（ use ‘-device virtio-net-pci’ option）

当然这并不意味着rtl8139和e1000是没有意义的，毕竟virtio需要在guest上面安装驱动。rtl8139和e1000在兼容的广泛度上占有优势。例如，如果ovirt的cpu不是x86，而是arm或者其它某些系列cpu，上述网卡未必全部支持。这点需要注意。

virtio-net-pci

7、在ubuntu下使用虚拟机

https://zhuanlan.zhihu.com/p/32125940 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/virtualization_deployment_and_administration_guide/sect-graphic_user_interface_tools_for_guest_virtual_machine_management-remote_viewer

8、Freedesktop.org

致力于Linux和其他类Unix上的X窗口系统的桌面环境之间的互操作性和基础技术共享的项目 freedesktop.org（fd.o）是一个致力于Linux和其他类Unix上的X窗口系统的桌面环境之间的互操作性和基础技术共享的项目。外文名Freedesktop.org成立时间2000年3月由红帽的HavocPennington于2000年3月创立。该组织关注用户。X有很多开发框架，将来很可能也这样。而该组织力求这其中的不同不会为最终用户所察觉。最流行的开源X桌面——GNOME、KDE和Xfce都与该项目紧密合作。在2006年该项目发布了Portland1.0(xdg-utils)，一个常用的桌面环境接口的集合。 freedesktop.org最初的名称叫XDesktopGroup（X桌面工作组），其缩写"XDG"在他们的工作中仍然经常被用到。

github：https://github.com/freedesktop/spice-usbredir

9、提高bulk设备传输速度

网络问题无法进行优化 bulk流只对in包有效，烧录是往设备里面写数据，因此是out包。修改端口的maxsize会有枚举问题，并且实际上跟这个无关，因为设备又不是根据这个进行发包的。可以修改设备描述符中maxsize值，可以提供映射速度。

10、pipeline变量

翻译成管道或者流水线。

AI回答：在QEMU中，USBEndpoint结构体中的pipeline变量通常用于控制USB数据包的传输流程。当pipeline变量为false时，表示数据包的传输是单向的，即只能进行数据的接收或发送。而当pipeline变量为true时，表示数据包的传输是双向的，即可以进行数据的接收和发送。这个变量的取值影响着USB数据包在端点中的传输方式，根据其取值不同，USB设备模拟会采取相应的传输逻辑来处理数据包的接收和发送。

不是很准确，通过代码来看pipeline默认为true时，bulk数据包会进行分包，把一个大包分成若干个小包，然后会进行分包和组包过程。在combined-packet.c文件中usb_combined_input_packet_complete函数。

实践发现，设置pipeline为false后，整体数据包传输速度变慢，数据包大小也变小了。

11、键盘按键适配

11-1、qemu不同版本现状

KeyboardTest工具下载：https://www.passmark.com/products/keytest/index.php 通过qemu的qemu_input_map_qnum_to_qcode的qnum序列来查找资料：https://aeb.win.tue.nl/linux/kbd/scancodes-6.html#msinternet

发现qemu2.5的Q_KEY_CODE_MAX = 125，而适配的韩语切换按键是242，因此在低版本的qemu无法进行适配。但确实也能在ui/sdl2-keymap.h搜索到Q_KEY_CODE_MAIL变量，但是却无法找到该变量的定义。但是有个问题就是242这个按键消息确实传递到了虚拟机内部，只不过显示为0xFF，说明应该是支持的，说明有遗漏。但是在qemu5.0.0版本中，242按键消息是没有发给虚拟机的，需要进行适配，需要修改qemu-5.0.0/ui/keycodemapdb/data/keymaps.csv、qemu-5.0.0/qapi/ui.json文件。 ui.json：是按键宏定义的配置文件，qemu编译时，根据里面配置生成qapi-util-ui.c文件，该文件定义了所有按键的宏定义，比如：上面截图的Q_KEY_CODE_XXX。 keymaps.csv：各种按键的转换表，qemu编译时，根据这边的内容生成input-keymap-qnum-to-qcode.c、input-keymap-qcode-to-atset2.c等源码，生成qcode、atset等按键表。

11-2、input-keymap-qnum-to-qcode.c文件内容生成

keymaps.csv文件中对于242并没有填写atset1和atset2信息，导致并没有生成到input-keymap-qnum-to-qcode.c文件中去。该文件通过qemu-5.0.0/ui/keycodemapdb/keymap-gen脚本生成，命令如下：

python3 keymap-gen --lang=glib2 --varname=qemu_inpu_map_atset1_to_qcode code-map data/keymaps.csv atset1 qcode
可以修改最后两个参数变量qemu_input_map_qnum_to_qcode 的索引就是其按键的scancode转换而来的，
索引小于0x80的，scancsode = 索引值，比如：[0x1] = Q_KEY_CODE_ESC，即esc按键的scancode为0x1
索引大于0x80的，scancsode = REDKEY_ESCAPE_BASE +（索引值 - 0x80），比如：[0xec] = Q_KEY_CODE_MAIL，即mail按键的scancode为REDKEY_ESCAPE_BASE + （0xec - 0x80）

添加atset1和atset2信息后就能把该按键信息生成了，但问题在于242按键的atset1和atset2信息是多少？

11-3、AT set1 keycode和AT set2 keycode

在 Linux 和其他操作系统中，AT（AT Keyboard）键盘的按键码（keycode）用于表示键盘上的特定按键。AT set1 和 AT set2 是两种不同的按键码集，通常用于不同的键盘布局或设备。

AT set1 是最早的 AT 键盘按键码集，通常用于标准的 PC 键盘。按键码的范围通常是从 1 到 255，具体的按键码与按键的功能一一对应。

11-4、atset1和atset2表

atset2 keycodes：https://www.libvirt.org/manpages/https://blog.weghos.com/qemu/qemu/build/ui/input-keymap-atset1-to-qcode.c.html 发现atset1和atset2信息表最大值只到了0xe07d值。

发现github和gitlab仓库显示内容略有不同（github打不开keycodemapdb，但是gitlab可以） https://gitlab.com/qemu-project/qemu/-/tree/stable-8.0/ui?ref_type=heads https://github.com/qemu/qemu/tree/stable-8.0/ui

开源qemu最终版： https://gitlab.com/qemu-project/keycodemapdb

github单独仓库： https://github.com/qemu/keycodemapdb/blob/master/data/keymaps.csv

最终适配方案：

KEY_VIDEO_NEXT,241,,,0xe071,0x19,,,VK_HANJA,0x19,,,,,,I249,hanja,,
KEY_VIDEO_PREV,242,,,0xe072,0x39,,,VK_HANGEUL,0x15,,,,,,I250,hangeul,,

qemu-5.0.0/ui/spice-input.c 修改kbd_push_key函数对于0xf1和0xf2按键（即>0x80）其keycode = scancode。

11-5、适配依据

至少atset1和atset2缺一不可，这也是最难获取到的值，其中VK_HANJA,0x19和VK_HANGEUL,0x15可以通过rawinputtool.exe程序获取，使用spy++不行，使用KeyboardTest.exe软件获取到了0x19，另外一个值是0xE5，有点差距。

对于atset1值，我们可以通过在qemu2.5.1版本（正常传递242和241按键）增加调试日志发现其qcode分别是113（0x71）和114（0x72），另外我们在https://www.libvirt.org/manpages/virkeycode-qnum.html找到其值。然后就可以推断其扩展键为0xe071和0xe072。对于atset2值，也是只能通过qemu2.5.1版本中的hw/input/ps2.c文件中的数组去获取，其对应113和114下标的25和57，即0x19和0x39。

/* Table to convert from PC scancodes to raw scancodes.  */
static const unsigned char ps2_raw_keycode[128] = {
  0, 118,  22,  30,  38,  37,  46,  54,  61,  62,  70,  69,  78,  85, 102,  13,
 21,  29,  36,  45,  44,  53,  60,  67,  68,  77,  84,  91,  90,  20,  28,  27,
 35,  43,  52,  51,  59,  66,  75,  76,  82,  14,  18,  93,  26,  34,  33,  42,
 50,  49,  58,  65,  73,  74,  89, 124,  17,  41,  88,   5,   6,   4,  12,   3,
 11,   2,  10,   1,   9, 119, 126, 108, 117, 125, 123, 107, 115, 116, 121, 105,
114, 122, 112, 113, 127,  96,  97, 120,   7,  15,  23,  31,  39,  47,  55,  63,
 71,  79,  86,  94,   8,  16,  24,  32,  40,  48,  56,  64,  72,  80,  87, 111,
 19,  25,  57,  81,  83,  92,  95,  98,  99, 100, 101, 103, 104, 106, 109, 110
};
static const unsigned char ps2_raw_keycode_set3[128] = {
  0,   8,  22,  30,  38,  37,  46,  54,  61,  62,  70,  69,  78,  85, 102,  13,
 21,  29,  36,  45,  44,  53,  60,  67,  68,  77,  84,  91,  90,  17,  28,  27,
 35,  43,  52,  51,  59,  66,  75,  76,  82,  14,  18,  92,  26,  34,  33,  42,
 50,  49,  58,  65,  73,  74,  89, 126,  25,  41,  20,   7,  15,  23,  31,  39,
 47,   2,  63,  71,  79, 118,  95, 108, 117, 125, 132, 107, 115, 116, 124, 105,
114, 122, 112, 113, 127,  96,  97,  86,  94,  15,  23,  31,  39,  47,  55,  63,
 71,  79,  86,  94,   8,  16,  24,  32,  40,  48,  56,  64,  72,  80,  87, 111,
 19,  25,  57,  81,  83,  92,  95,  98,  99, 100, 101, 103, 104, 106, 109, 110
};

keycode是Windows键码 scancode是BIOS键码发现114刚好等于242-0x80，113刚好等于241-0x80。

qemu_input_map_qnum_to_qcode 的索引就是其按键的scancode转换而来的，索引小于0x80的，scancsode = 索引值，比如：[0x1] = Q_KEY_CODE_ESC，即esc按键的scancode为0x1 索引大于0x80的，scancsode = REDKEY_ESCAPE_BASE +（索引值 - 0x80），比如：[0xec] = Q_KEY_CODE_MAIL，即mail按键的scancode为REDKEY_ESCAPE_BASE + （0xec - 0x80） REDKEY_ESCAPE_BASE = 0x100 REDKEY_APP_MAIL = REDKEY_ESCAPE_BASE + 0x6c

12、Windows7系统适配xhci主控

'ich9-usb-xhci'  => { bus => 0, addr => 27 },
my $pciaddr_xhci = print_pci_addr("ich9-usb-xhci");
push @$cmd, '-device', "nec-usb-xhci,id=xhci${pciaddr_xhci}.0x0";

my $USB_XHCI_INDEX_START = 0;
my $USB_XHCI_INDEX_END = 12;
for ( my $i = $USB_XHCI_INDEX_START ; $i < $USB_XHCI_INDEX_END ; $i++ ) {
    my $portid = $i - $USB_XHCI_INDEX_START + 1;
    push @$cmd, '-chardev', "spicevmc,id=charredir$i,name=usbredir";
    push @$cmd, '-device',  "usb-redir,chardev=charredir$i,id=redir$i,bus=xhci.0,port=$portid";
}
$camera_num = 2;
for ( my $j = $camera_num ; $j < $camera_num + 2 ; $j++ ) {
    my $portid = 14 + $j;
    push @$cmd, '-chardev', "spicevmc,id=charrd$j,name=usbredir";
    push @$cmd, '-device',  "redir-video,chardev=charrd$j,id=redirrd$j,bus=xhci.0,port=$portid";
}

虚拟机内部就会出现通用串行总线（USB）控制器未安装驱动，之前把intel的usb3.0驱动尝试一遍都没有正确安装。最终通过360驱动大师解决了驱动问题。

这个没啥用，主要是制作win7镜像：https://gitcode.com/open-source-toolkit/658e1/overview

12-1、intel usb3.0驱动和renesas usb3.0驱动

Intel 和 Renesas 是两家知名的芯片制造商，它们分别提供 USB 3.0 控制器和相应的驱动程序。

Intel USB 3.0 驱动程序通常与 Intel 芯片组的主板和处理器紧密集成，提供良好的兼容性和性能。 Renesas USB 3.0 驱动程序通常用于 Renesas 生产的 USB 3.0 控制器，广泛应用于各种主板和外部 USB 设备。硬件 ID 通常会包含厂商 ID 和设备 ID，例如 PCI\VEN_8086&DEV_1E31，其中 VEN_8086 表示 Intel（厂商 ID）。硬件 ID 通常会包含厂商 ID 和设备 ID，例如 PCI\VEN_1033&DEV_0194，其中 VEN_1033 表示 Renesas（厂商 ID）。

12-2、Windows7虚拟机xhci主控assert异常

kvm: hw/usb/hcd-xhci.c:902: xhci_events_update: Assertion `intr->er_full' failed.

一头雾水，然后就去看开源代码，发现qemu2.5源码就是这样写的，然后发现qemu3.0版本已经没有异常的函数了，然后最终找到stable-2.9版本开始删除该函数的，然后找寻删除代码的提交记录：

https://gitlab.com/qemu-project/qemu/-/commit/898248a32915024a4f01ce4f0c3519509fb703cb

xhci: drop ER_FULL_HACK workaround

The nec/renesas driver problems have finally been debugged and root
caused, see commit "7da76e12 xhci: fix event queue IRQ handling".

大体意思是在"7da76e12 xhci: fix event queue IRQ handling"解决了问题，然后该函数就没有存在必要了，因此重点在另外一个提交记录：
https://gitlab.com/qemu-project/qemu/-/commit/7da76e12cc5cc902dda4c168d8d608fd4e61cbc5

根据这个提交记录修改后，测试设备正常挂载到qemu2.5版本的Windows7系统的xhci主控上面。但是仔细分析修改内容弄不懂，放弃纠结。

12-3、驱动签名SHA-2算法

SHA-1和SHA-2（SHA256）

把所有的KB补丁卸载完后，驱动程序报错： Windows无法验证此设备所需的驱动程序的数字签名。最近的硬件或软件更改安装的文件可能未正确签名或已损坏，或者可能是来自未知来源的恶意软件。（代码 52）此时可以禁用驱动程序签名强制：控制台重启虚拟机，快速按F8键（也可进入安全模式），或者BIOS延迟开机时间注意开启测试模式不行： BCDEDIT -SET LOADOPTIONS DISABLE_INTEGRITY_CHECKS BCDEDIT -SET TESTSIGNING ON

另外的方法是打Windows补丁：KB3033929即可（主要支持sha256证书https://blog.csdn.net/xcntime/article/details/142711945）。 Windows补丁网站：https://www.catalog.update.microsoft.com/home.aspx 适用于 x64 系统的 Windows 7 Service Pack 1 (KB976932) ，即Windows7升级到sp1版本

12-4、接12-4关闭驱动签名验证后报新的错误

Windows 无法初始化这个硬件的设备驱动程序。（代码 37）想不通，在客户的win7旗舰版环境本地就存在一个6.2.9200.22453驱动，签名是RioLin Limited，通过dism++软件导出到内部环境安装后就会报上面的错误，将此驱动安装到win10虚拟机就是正常的。

内部win7虚拟机通过驱动人生和360驱动大师安装的版本是2.1.39.0。

最终在这个网站找到了客户的驱动安装包：https://winraid.level1techs.com/t/solve-the-turbo-problem-of-intel-12th-to-14th-cpus-on-win7/99752 https://disk.yandex.ru/d/rTMlnh8LKT43Jg

12-5、PCI-Z 设备硬件检测

PCI-Z 是一款专为 Windows 系统设计的硬件检测工具。它能够提供关于 PCI（包括 PCI-E、PCI-X 等）设备的详细信息，帮助用户识别和解决未知硬件的问题。

官网：https://www.pci-z.com 通过此软件发现硬件信息为uPD720200 USB 3.0 Host Controller，1033:019A，发现win10虚拟机和多台服务器就是这个型号，虽然未看客户的，基本确定应该是一样的。

然后win7虚拟机直接把win10虚拟机的xhci主控驱动安装，报错： Windows 无法初始化这个硬件的设备驱动程序。驱动程序可能已损坏或不见了。（代码 39）

12-6、PCI-Z软件驱动搜索下载

谷歌搜索方式：NEC Corporation uPD720200 USB 3.0 Host Controller Microsoft Windows 7 driver https://www.station-drivers.com/index.php?option=com_remository&Itemid=353&func=fileinfo&id=119&lang=en 可用，版本也是2.1.39.0。

CPU-Z：https://www.cpuid.com/softwares/cpu-z.html PCI-Z 中的 Z 代表 "Zero"，强调其对 PCI 设备的管理功能。 CPU-Z 中的 Z 没有特定的含义，主要是作为软件名称的一部分，用于区分和标识该工具。

12-7、qm monitor命令

qm monitor $vmid
info usb
info pci
info version
info qtree

12-8、客户的win7驱动安装到win10虚拟机

测试安装正常，然鹅在重启虚拟机后发现虚拟机蓝屏了，蓝屏代码：KERNEL_SECURITY_CHECK_FAILURE (139) 然后虚拟机怎么都起不来，一启动就蓝屏。

进入安全模式，无果，根本没有启动设置选项（https://www.jianshu.com/p/5101eb1cd1a9），只有命令行能使用。连续三次重启电源的方式也行不通。（如果连续三次引导尝试失败，Windows 10将在第四次尝试时引导到自动修复模式。） F8按键。

最终发现ucx01000.sys驱动文件是罪魁祸首，它的签名只有RioLin Limited，正常来说win10系统是需要微软签名的，但是在命令行窗口使用del命令删除文件后还是蓝屏，发现ucx01000.sys驱动文件又恢复回来了，原来是该文件在注册表中存在。只能通过PE系统进去虚拟机，然后手动删除ucx01000.sys驱动文件后是能正常启动虚拟机的，而且ucx01000.sys驱动文件是恢复回来的，这时候发现xhci主控是感叹号状态，设备状态是Windows 无法初始化这个硬件的设备驱动程序。（代码 37）找不到对象名。此时xhci主控驱动没法装其他驱动，说是最新的，而且没法卸载。

这时候删除计算机\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ucx01000注册表后，ucx01000.sys驱动文件不再恢复，解决蓝屏问题，也解决了xhci主控是感叹号状态，成功卸载了win7驱动。但是xhci主控变成了符合 USB xHCI 的主机控制器，并且设备状态还是Windows 无法初始化这个硬件的设备驱动程序。（代码 37）找不到对象名。

最终个人感觉应该需要ucx01000.sys驱动文件（依据是USBXHCI主控服务里面有写DepenOnService为Ucx010000），然后从另外一台虚拟机把ucx01000.sys驱动文件注册表导入进去，并把ucx01000.sys驱动文件放在C:\Windows\System32\drivers目录，问题最终解决。

12-9、解决客户环境能正常加载ucx01000.sys驱动问题

通过查看客户环境的Windows补丁安装情况，发现有windows6.1-kb2685811-x64_191e09df632b70fd4f4b27d4cb9227f7c5a1c98c.msu和windows6.1-kb2685813-x64_22a969bada171678b0936bb320e6a7778e8adc07.msu，其中发现kb2685811内核模式驱动框架安装后xhci驱动就正常了。对于驱动签名情况后面有时间再研究，暂时没有啥影响。

13、qemu开启asan内存检查

asan内存扫描需要gcc4.9版本后支持，目前debian源服务器的gcc5.4要求libc 2.14以上版本），而我们打包环境的libc是2.13版本，无法通过源服务安装。解决方案：代码编译gcc到5.4版本，并使用gcc 5.4对qemu、spice server等模块进行编译。 gcc源码下载：http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-5.4.0/

./configure --prefix=/usr/local/gcc-5.4.0 --enable-threads=posix --disable-checking --disable-multilib --enable-languages=c,c++
make -j4
make install

编译需要依赖mpfr-2.4.2、gmp-4.3.2、mpc-0.8.1等等，需要把缺少的东西都需要弄过来，才能编译出需要的gcc版本。

export CXXFLAGS="-g -O0 -Werror-implicit-function-declaration -fsanitize=address -fno-omit-frame-pointer -lasan"
export CFLAGS="-g -O0 -Werror-implicit-function-declaration -fsanitize=address -fno-omit-frame-pointer -lasan"
export LDFLAGS="$LDFLAGS -Werror-implicit-function-declaration -fsanitize=address -fno-omit-frame-pointer -lasan"
ldd qemu-system-x86_64 | grep asan
需要把libasan.so.2文件拷贝到运行环境

虚拟机需要启动脚本运行才能加载生效：

#!/bin/bash

vmid=8521035828450
qm-c stop ${vmid}

rm -f asan/asan.log.*

export ASAN_OPTIONS="halt_on_error=0:disable_coredump=0:unmap_shadow_on_exit=1:abort_on_error=1:detect_leaks=1:malloc_context_size=15:log_path=/data/local/asan/asan.log"

cmd=$(qm showcmd ${vmid})
cmd1=$(echo $cmd | sed -e 's/password=/password=f837667a/g')
$cmd1

使用jemalloc自带的内存检查功能

14、0x80异常端点解析导致qemu崩溃

#2 0x00007f0bf78cc621 in_assert_fail ()from /1ib/x86_64-linux-gnu/libc.so.6
#3 0x000055ce4af58361 in usb handTe_packet (dev=0x7fobe7bf4800，p=0x7f0be05f7030) at hw/usb/core.c:410
#4 0x000055ce4af763aa in xhci fire ctl transfer (xhci=0x7fob55000000，xfer=0x7f0be05f7028) at hw/usb/hcd-xhci.c:1969
#5 0x000055ce4af7700a in xhci_kick_ep(xhci=0x7f0b55000000，slotid=1,epid=1, streamid=0) at hw/usb/hcd-xhci.c:2210
#6 0x000055ce4af7a10f in xhci_doorbell_write (ptr=0x7f0b55000000，reg=1，val=1, size=4) at hw/usb/hcd-xhci.c :3384
#7 0x000055ce4ac9aa49 in memory_region_write_accessor (mr=0x7f0b55000d50，addr=4，value=0x7f0be0ffe8e8，size=4，shift=0，mask=4294967295，attrs=...) at /home/vtcompile/buildenv/Trunk/source/app/qemu/qemu-2.5.1/memory.c:451
#8 0x000055ce4ac9ac5b in access_with_adjusted_size (addr=4，value=0x7f0be0ffe8e8，size=4,access_size_min=1,access_size_max=4,access=0x55ce4ac9a9bf {<}memory_region_write_accessor{>} mr=0x7f0b55000d50， attrs=...) at /home/vtcompile/buildenv/Trunk/source/app/qemu/qemu-2.5.1/memory.c:507
#9 0x000055ce4ac9dd05 in memory_region_dispatch_write(mr=0x7f0b55000d50，addr=4，data=1,size=4, attrs=...) at /home/vtcompile/buildenv/Trunk/source/app/qemu/qemu-2.5.1/memory.c:1159
#10 0x000055ce4ac3ec57 in address_space_rw(as=0x55ce4b7d5200，addr=4227948548，attrs=...,buf=0x7f0bfe6e1028{<}Address 0x7f0bfe6e1028 out of bounds{>},len=4, is_write=true)

for (i = 0; i < ifp->bNumEndpoints; i++) {
    struct libusb_endpoint_descriptor ep;
    usbi_parse_descriptor(buffer, "bbbbwb", &ep, host_endian);
    if (ep.bDescriptorType == LIBUSB_DT_ENDPOINT && (ep.bEndpointAddress & 0x0F) == 0) {
        usbi_warn(ctx, "an invalid endpoint with address 0x%02X, skipping(%d)",
            ep.bEndpointAddress, ep.bLength);
        buffer += ep.bLength;
        parsed += ep.bLength;
        size   -= ep.bLength;
        ifp->bNumEndpoints = (uint8_t)i;
        break;
    }
}

15、usb1.0协议设备可以挂载xhci主控

只有ehci主控才需要注意uhci主控的位置，否则报错Warning: speed mismatch trying to attach。

16、ubuntu安装qemu

apt install qemu-system

qemu ​

1、官网 ​

2、简介 ​

3、在qemu中模拟设备 ​

4、理解qemu中的xhci实现 ​

5、追踪CR_STOP_ENDPOINT命令 ​

6、根据google查找原因 ​

os-posix:273 kvm: -device nec-usb-xhci,id=xhci,bus=pci.0,addr=0x1b.0x0: 'nec-usb-xhci' is not a valid device model name ​

ovirt几种网卡（e1000, rtl8139, virtio）的简要说明 ​

7、在ubuntu下使用虚拟机 ​

8、Freedesktop.org ​

9、提高bulk设备传输速度 ​

10、pipeline变量 ​

11、键盘按键适配 ​

11-1、qemu不同版本现状 ​

11-2、input-keymap-qnum-to-qcode.c文件内容生成 ​

11-3、AT set1 keycode和AT set2 keycode ​

11-4、atset1和atset2表 ​

11-5、适配依据 ​

12、Windows7系统适配xhci主控 ​

12-1、intel usb3.0驱动和renesas usb3.0驱动 ​

12-2、Windows7虚拟机xhci主控assert异常 ​

12-3、驱动签名SHA-2算法 ​

12-4、接12-4关闭驱动签名验证后报新的错误 ​

12-5、PCI-Z 设备硬件检测 ​

12-6、PCI-Z软件驱动搜索下载 ​

12-7、qm monitor命令 ​

12-8、客户的win7驱动安装到win10虚拟机 ​

12-9、解决客户环境能正常加载ucx01000.sys驱动问题 ​

13、qemu开启asan内存检查 ​

14、0x80异常端点解析导致qemu崩溃 ​

15、usb1.0协议设备可以挂载xhci主控 ​

16、ubuntu安装qemu ​