Dear QEMU list members, We developed a virtual machine using the QEMU code. This virtual machine emulates a certain custom-made computer that runs on a certain military platform. All I can tell you about this virtual machine is that it emulates a computer that has an e5500 processor. Currently I am running this virtual machine on a T4240-RDB which has a PowerPC e6500 processor (if anyone remembers me posting about this same project earlier, we fixed the TCG problem thanks to you guys!).
Anyway, right now I'm trying to get this virtual machine working with KVM enabled. It should work given that the virtual machine is emulating an e5500 processor and it's running on a board with an e6500 processor. We're also using a kernel I built using Yocto and I'm pretty sure KVM is all good and working in this kernel (this was a whole story in it of itself, but if you're curious you can see my post history concerning getting KVM in the kernel). But for some reason the VM hangs on an ioctl call when KVM is enabled and nothing else happens. Now I don't think this hanging is necessarily the problem. I think what might be the case is that after the VM makes the ioctl call, the VM should start running the operating system. But this doesn't seem to be happening; when I look at "info registers" I see that the NIP has the address of the start instruction of the operating system but nothing changes and the NIP doesn't progress from that point. Let me give some further detail on the subject. With some investigation using print statements/breakpoints I see that the VM enters into the following function call in the code (I included the call stack): qemu_kvm_cpu_thread_fn -> kvm_cpu_exec(cpu) -> kvm_vcpu_ioctl(cpu, KVM_RUN, 0) -> ioctl(cpu->kvm_fd, KVM_RUN, arg) So the VM enters into a kernel level ioctl call of type KVM_RUN. And after putting some print statements into the Yocto kernel itself I see that the VM enters into a function in the kernel code called kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu) and then enters a function calling assembly code like so: ret = __kvmppc_vcpu_run(kvm_run, vcpu). At this point since __kvmppc_vcpu_run() is a function calling assembly code in the kernel, I have not been able to follow this call any further. But looking over the assembly code of this function I see some swapping of vCPU and host registers as well as a return-from-interrupt instruction at the end. See assembly code taken from bookehv_interrupts.S: https://gist.github.com/WayneZhenLi/137a748dad3eebc9be6e9b7b1a49268e At this point I have two theories on what is happening: 1. __kvmppc_vcpu_run is hitting the return from interrupt and the NIP of the VM is set to the start address of the operating system. But for some KVM-related reason, the operating system isn't able to progress and we see the NIP stuck at the starting address. 2. The return from interrupt is either not being reached or is sending me to some unknown address and thus the operating system is never run. Perhaps I see the NIP in "info registers" pointed at the starting address because of some startup thing QEMU does. But maybe this doesn't reflect the actual position of the VM? One more symptom of something not being quite right is this all describes the second KVM_RUN ioctl call being run. Before this ioctl call, there is actually another KVM_RUN ioctl call that runs and completes, but fails with an error saying "kvm_run failed Interrupted system call". I'm not sure how relevant that is but I just wanted to mention it in case it's important. Anyway, I'm really not sure what the problem is. This is everything I know at the moment but I really don't a have a good idea on why the operating system code isn't being run. Please let me know your thoughts. -Thanks!, Wayne Li
