Re: Fwd: Upstream QEMU vs kvm modified for ARM implementation
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Upstream QEMU vs kvm modified for ARM implementation
Hi Hollis. Thanks a lot for getting back to us. The PPC code is indeed very intelligible... We took the approach, which you recommended earlier regarding test code, and are writing kind of a test harness in the same spirit, which we will eventually throw into the QEMU source. Previously we were informed on the KVM #irc channel that the QEMU upstream version of KVM was not functional, but I guess it was s mild overstatement then. 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? - 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? - Is compiling against a patched kernel (as opposed to using a module) and doing sync-headers from custom source supported in the upstream version? Any specific tag of the QEMU git repository you recommend working from, or would the latest commit usually be trustworthy? :) 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? Regards, Christoffer Dall & Andreas Nilsson Columbia University On Tue, Apr 7, 2009 at 2:11 PM, Hollis Blanchard wrote: > On Tue, 2009-04-07 at 12:41 -0400, Christoffer Dall wrote: >> Hi. >> >> As we indicated earlier, we are working on an ARM version of KVM and >> taking some inspiration from the PPC version. > > I hope the PPC code is intelligible to you... feel free to ask if you > have design questions we can help clarify. > >> We have done some amount of kernel side development and are now >> looking more into adapting QEMU. > > By the way, you can start with kvm-userspace/test/ code to begin > exercising your kernel interface before qemu is ready. > >> First, is it correct that the PPC port of KVM uses the kvm-all.c files >> and thus the upstream QEMU support for KVM? > > Correct. > >> Second, for an ARM version, which takes the same approach with >> replacing interrupt vectors in the kernel as PPC, would the best >> approach be to continue with the upstream QEMU version or try to use >> the structure used in the by qumranet modified qemu version for >> x86_64? > > There isn't an architectural split like that (PowerPC -> upstream, x86 > -> Qumranet). Previously, all KVM support (including PowerPC) was in the > Qumranet fork, but now upstream has support for PowerPC and x86. There > are still features that need to be migrated upstream though (e.g. guest > SMP). > > You should base your work on upstream qemu. If you base it on the > Qumranet fork, nobody will migrate your code upstream for you, and long > term that fork is expected to disappear (when upstream becomes > feature-complete). > > Also, the interrupt vectors thing really doesn't matter... the kernel > provides an interface, and how exactly that's implemented doesn't matter > to qemu. > >> Last, we are using the kvm-84 release of userspace kvm and QEMU - >> would this also be what you would recommend working with? > > Use qemu.git (http://git.kernel.org/?p=virt/qemu/qemu.git;a=summary). > > -- > Hollis Blanchard > IBM Linux Technology Center > > -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Upstream QEMU vs kvm modified for ARM implementation
On Tue, 2009-04-07 at 12:41 -0400, Christoffer Dall wrote: > Hi. > > As we indicated earlier, we are working on an ARM version of KVM and > taking some inspiration from the PPC version. I hope the PPC code is intelligible to you... feel free to ask if you have design questions we can help clarify. > We have done some amount of kernel side development and are now > looking more into adapting QEMU. By the way, you can start with kvm-userspace/test/ code to begin exercising your kernel interface before qemu is ready. > First, is it correct that the PPC port of KVM uses the kvm-all.c files > and thus the upstream QEMU support for KVM? Correct. > Second, for an ARM version, which takes the same approach with > replacing interrupt vectors in the kernel as PPC, would the best > approach be to continue with the upstream QEMU version or try to use > the structure used in the by qumranet modified qemu version for > x86_64? There isn't an architectural split like that (PowerPC -> upstream, x86 -> Qumranet). Previously, all KVM support (including PowerPC) was in the Qumranet fork, but now upstream has support for PowerPC and x86. There are still features that need to be migrated upstream though (e.g. guest SMP). You should base your work on upstream qemu. If you base it on the Qumranet fork, nobody will migrate your code upstream for you, and long term that fork is expected to disappear (when upstream becomes feature-complete). Also, the interrupt vectors thing really doesn't matter... the kernel provides an interface, and how exactly that's implemented doesn't matter to qemu. > Last, we are using the kvm-84 release of userspace kvm and QEMU - > would this also be what you would recommend working with? Use qemu.git (http://git.kernel.org/?p=virt/qemu/qemu.git;a=summary). -- Hollis Blanchard IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Upstream QEMU vs kvm modified for ARM implementation
Hi. As we indicated earlier, we are working on an ARM version of KVM and taking some inspiration from the PPC version. We have done some amount of kernel side development and are now looking more into adapting QEMU. First, is it correct that the PPC port of KVM uses the kvm-all.c files and thus the upstream QEMU support for KVM? Second, for an ARM version, which takes the same approach with replacing interrupt vectors in the kernel as PPC, would the best approach be to continue with the upstream QEMU version or try to use the structure used in the by qumranet modified qemu version for x86_64? Last, we are using the kvm-84 release of userspace kvm and QEMU - would this also be what you would recommend working with? Some help here would be greatly appreciated! Thanks, Christoffer Dall -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
