内核发生了hard LOCKUP然后panic了，代码版本是linux-3.10.0-514.16.1.el7.x86_64
[4474426.249700] NMI watchdog: Watchdog detected hard LOCKUP on cpu 50
crash下的bt信息如下： [exception RIP: tg_unthrottle_up+24] RIP: ffffffff810c9658 RSP: ffff882f7fc83dc8 RFLAGS: 00000046 RAX: fff...
代码版本：linux-git v4.10.0-rc3
1.kvm clock时钟
[crayon-5efd7c8c880c4909401662/]
1）KVM clock 在guest中：
kvmclock_init负责在guest启动过程中初始化kvm clock，首先更新了两个MSR值：
#define MSR_KVM_WALL_CLOCK_NEW 0x4b564d00
#define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01
然后为每个CPU分配struct...
Base是git://git.qemu.org/qemu.git v2.6.0
入口是qemu_init_vcpu，在tcg_enabled下进入qemu_tcg_init_vcpu函数，在qemu_thread_create(cpu->thread, thread_name, qemu_tcg_cpu_thread_fn,
cpu, QEMU_THREAD_JOINABLE)中看到执行函数是qemu_tcg_cpu_thread_fn，下面的函数负责控制在machine完全初始化完成前进行等...
在SIMICS软件里面模拟最新的CPU进行虚拟化测试的时候，先把Dave的kernel patches拿到手，打补丁到v4.1-rc2上，每次启动qemu-kvm的时候，console上就打印了一堆信息，然后panic了，信息简略如下：
[crayon-5efd7c8c88e2a954105291/]
先是反汇编内核，看到了出问题的地方，在kvm_cpu_vmxon函数上，它就是汇编执行vmx...
还是神奇的进程调度问题引发的，参看Linux进程组调度机制分析，组调度机制是看清楚了，发现在重启过程中，很多内核调用栈阻塞在了double_rq_lock函数上，而double_rq_lock则是load_balance触发的，怀疑当时的核间调度出现了问题，在某个负责场景下产生了多核互锁，后面看了一下CPU负载平衡下的代码实现，写一下总结。
...
又碰到一个神奇的进程调度问题，在系统重启过程中，发现系统挂住了，过了30s后才重新复位，真正系统复位的原因是硬件看门狗重启的系统，而非原来正常的reboot流程。硬件狗记录的复位时间，将不喂狗的时间向前推30s分析串口记录日志，当时的日志就打印了一句话：“sched: RT throttling activated”。
从linux-3.0.101-0.7...
在虚拟机的创建与运行章节里面笼统的介绍了KVM在qemu中的创建和运行，基本的qemu代码流程已经梳理清楚，后续主要写一些硬件虚拟化的原理和代码流程，主要写原理和qemu控制KVM运行的的ioctl接口，后续对内核代码的梳理也从这些接口下手。
QEMU：git://git.qemu.org/qemu.git v2.4.0
KVM：https://git.kernel.org/pu...
前段时间挖了一个坑，KVM源代码分析1:基本工作原理，准备写一下kvm的代码机制，结果一直没时间填土，现在还一下旧账，争取能温故而知新。 基本原理里面提到kvm虚拟化由用户态程序Qemu和内核态驱动kvm配合完成，qemu负责HOST用户态层面进程管理，IO处理等，KVM负责把qemu的部分指令在硬件上直接实现，从虚拟机的创建和运...
死锁就是多个进程（线程）因为等待别的进程已占有的自己所需要的资源而陷入阻塞的一种状态，死锁状态一旦形成，进程本身是解决不了的，需要外在的推动，才能解决，最重要的是死锁不仅仅影响进程业务，而且还会占用系统资源，影响其他进程。所以内核中设计了内核死锁检测机制，一旦发现死锁进程，就重启OS，快刀斩乱麻解...
13年的时候准备挖“KVM源代码分析”的坑，陆陆续续2年过去了，坑也没有填上，当时是因为对KVM了解的肤浅，真正的理解必然要深入到代码级别，所谓“摈弃皮毛，看到血肉，看到真相”，当时计划写KVM基本工作原理、虚拟机的创建、VCPU调度原理、KVM内存管理、KVM设备管理等，实际发现代码过程还是很多，估计后续会针对于不同的...
