2008/11/13 Anthony Liguori <[EMAIL PROTECTED]>: > andrzej zaborowski wrote: >> Is this going a bit in the opposite direction to where QEMUAccel is >> going? What Fabrice suggests seems to be like QEMUAccel, with TCG >> treated as another accelerator. >> > > QEMUAccel is a bit orthogonal to what I'm talking about. There is already > KVM support in QEMU today and I'm merely looking to restructure existing > code so that I can build a version of QEMU that has no TCG support, only KVM > support. TCG is too intimately woven into QEMU right now. You could think > of this perhaps as a precursor to making TCG more of an "accelerator" than > it is today.
Ah, I agree with your patch, I was only commenting on the idea of *-kvm/ targets. I see something like QEMUAccel as a way to turn on and off the cpu emulators (TCG, kvm, kqemu). Ofcourse, kqemu depends on a fallback emulator - currently TCG - I guess it could be possible to run kqemu with kvm as the fall back and not compile in TCG (even if not a very useful configuration). > > But wrt QEMUAccel and KVM, there are 5 places in QEMU where there is KVM > specific code. > > One is cpu-exec.c to invoke the kvm exec routine instead of TCG. kqemu has > something similar. Unfortunately, kqemu relies on some state that's only > available in cpu-exec.c so we can't make this a single function pointer > invocation without major surgery on cpu-exec. > > One is vl.c to initialize KVM support. kqemu doesn't need this. > > One is exec.c, to hook cpu_register_physical_memory. kqemu does this too so > it could conceivably be a hook. > > Another one is monitor.c to implement 'info kvm'. Not really a place for a > hook. Ideally we could register the monitor callback from kvm-all.c when we > initialize KVM. > > Finally, there is a hook in hw/acpi.c to disable SMM support when using KVM. > This is KVM specific because KVM doesn't support SMM. kqemu uses TCG to > run SMM code. > > Since there is only one shared hook ATM, I don't think something like > QEMUAccel is all that useful for KVM. On the other hand, there are 42 > places that are kqemu specific. I think kqemu could be refactored to > eliminate most of these. > > kqemu relies on TCG so you can't really decouple them from each other. > >> BTW It would be great if before merging a change like this you >> review/merge the patches submitted to the list that might touch the >> same area so as not to break them (such as Jan Kiszka's >> single-stepping/watchpoint fixes). >> > > Yeah, I will make sure to. Many thanks for that. Regards -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
