On Tue, 2009-04-07 at 14:30 -0400, Christoffer Dall wrote: > > A few questions regarding the upstream version: > - Apart from issues like SMP, are you aware of any specific problems > with the upstream version that we should be aware of? I don't know the full status off the top of my head (you might ask on qemu-devel), but many of them don't matter on non-x86 platforms. For example, I think qemu still doesn't support x86's in-kernel APIC emulation... but that's irrelevant for us. > - Does the upstream QEMU code use the libkvm code as well or is all > the logic placed in kvm-all.c and in the target specific kvm.c files? The latter. libkvm has a questionable future. > - Is compiling against a patched kernel (as opposed to using a > module) and doing sync-headers from custom source supported in the > upstream version? I have only used a real kernel build. I've had nothing but trouble with the kvm-userspace/kernel directory. Also, for technical reasons, the 440/e500 KVM build doesn't work as a module (we assume we will not take a TLB miss when handling guest exits). > Any specific tag of the QEMU git repository you recommend working > from, or would the latest commit usually be trustworthy? :) The latest is fairly trustworthy. There is a relatively high patch rate, but most of it is in areas that don't affect us. > Regarding the design of things, why was it necessary to hijack all > interrupt vectors in the kernel. We are wondering if it wouldn't be > sufficient to hijack synchronous interrupts and let QEMU take care of > all I/O, timer interrupts etc. Are we missing something here? We would love to do that, but the biggest problem is that the host interrupt handlers don't know about "guest state." PowerPC hardware does not switch the stack pointer for you; it's a software decision. When the host kernel sees the interrupt occurred in user mode, it switches the stack pointer to the top of the kernel stack. (If the interrupt occurred in kernel mode, the stack pointer is just decremented, preserving the kernel call stack.) When we run the guest, we run it in user mode. Since that's done via ioctl, there are frames from the ioctl path on the kernel stack. So if a host handler sees "came from user mode" and resets the kernel stack, we will clobber the ioctl stack frames. Anyways, the really high-level overview of our async handler path is that we restore host kernel register state then re-invoke the interrupt, so the host handlers will deal with it anyways. Note that (in general) with KVM, Qemu only handles IO. KVM handles all core emulation, including instructions, the MMU, and the decrementer (PowerPC's in-core timer interrupt source). -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
