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 <hollisb@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
